The Problem of File Sharing

All version control systems have to solve the same fundamental problem: how will the system allow users to share information, but prevent them from accidentally stepping on each other's feet? It's all too easy for users to accidentally overwrite each other's changes in the repository.

The lock-modify-unlock solution

Same time same file only one can be allowed to write, and the file couldn’t be unlocked until the one has its lock checked in.

The Copy-Modify-Merge Solution

Subversion, CVS, and many other version control systems use a copy-modify-merge model as an alternative to locking. In this model, each user's client contacts the project repository and creates a personal working copy—a local reflection of the repository's files and directories. Users then work simultaneously and independently, modifying their private copies. Finally, the private copies are merged together into a new, final version. The version control system often assists with the merging, but ultimately, a human being is responsible for making it happen correctly.

SVN, CVS和许多其它版本控制系统使用一种复制-修改-合并模型作为锁定-修改-解锁模型的变通. 在这个模型中, 每一个用户连接到项目文件仓库, 取出一份个人工作的副本-一个项目文件和目录的本地映射. 然后用户同时和独立的工作, 修改他们各自的副本. 最后, 这些各自的副本合并到一起形成一个新的, 最终的版本. 这种版本控制系统通常由合并工具来辅助. 但是最终, 还是由人来负责正确的操作.

 

 

Here's an example. Say that Harry and Sally each create working copies of the same project, copied from the repository. They work concurrently and make changes to the same file A within their copies. Sally saves her changes to the repository first. When Harry attempts to save his changes later, the repository informs him that his file A is out of date. In other words, file A in the repository has somehow changed since he last copied it. So Harry asks his client to merge any new changes from the repository into his working copy of file A. Chances are that Sally's changes don't overlap with his own; once he has both sets of changes integrated, he saves his working copy back to the repository.

But what if Sally's changes do overlap with Harry's changes? What then? This situation is called a conflict, and it's usually not much of a problem. When Harry asks his client to merge the latest repository changes into his working copy, his copy of file A is somehow flagged as being in a state of conflict: he'll be able to see both sets of conflicting changes and manually choose between them. Note that software can't automatically resolve conflicts; only humans are capable of understanding and making the necessary intelligent choices. Once Harry has manually resolved the overlapping changes—perhaps after a discussion with Sally—he can safely save the merged file back to the repository.

 

The Installation and Configuration of SVN

Installation

1.       Download, go to URL:    http://subversion.tigris.org/project_packages.html to get a new copy of SVN.

2.       Install the copy to a directory, for example C:\Program Files\Subversion

3.       and make sure that the directory like ‘C:\Program Files\Subversion \bin’ is included in environment variable %PATH%. If it is not in %PATH%, add it manually.

Install SVN Service

You should use sc.exe in Windows system to install svnserve.exe as a windows service.

The command is like:

sc create SVN binpath= "D:\Program Files\Subversion\bin\svnserve.exe --service -r D:\svnData" displayname= "Subversion Server" depend= Tcpip start= auto

Note:

1.       sc.exe is a tool of Windows system, not a tool in SVN installation directory.

2.       There should be a blank space between the arguments of sc.exe and their value.

Like: binpath=[blank space]“D:\ Subversion\bin\svnserve.exe --service -r D:\svnData"

           displayname= [blank space]"Subversion Server"

depend=[blank space]Tcpip

start=[blank space]auto       

3.       It needs administrator privilege to execute this command.

4.       After this command being executed successfully, you’d better start the service, using net start svn.

Configuration

Create repository

Use svnadmin to create your repository, command example: svnadmin create D:\code\svn

If it is executed successfully, you can find many file created by SVN in that directory.

 

Set Access Configuration

Go to your repository’s conf directory like D:\code\svn\conf , and edit the files as below:

1.       svnserve.conf

[general]

anon-access = none      # Anonymous users don’t have any access privilege

auth-access = write       #Authenticated user have write access privilege

password-db = passwd                   # password database is located in passwd file

authz-db = authz            # authorization control file is located in authz file

2.       passwd

You can create user and its password in this file.

Like:

ivar = iar           # means you added a user whose name is ivar and password is ivar.

3.       authz

In this file you can control users’ access privilege. Add the code as below:

[/]

ivar = rw           #  means user ivar has both read and write rights in repository’s root

#  directory.

 

Validating your configuration

After you finished all theabove steps, you can check your SVN service working status by using:

svn info svn://localhost/

If all is ok, it will response like this:

D:\SvnTest\Sample>svn info svn://localhost

路径: localhost

URL: svn://localhost

版本库根: svn://localhost

版本库 UUID: 17501bb3-fbbd-3942-be89-c0b0afec1a40

版本: 4

节点种类: 目录

最后修改的作者: ivar

最后修改的版本: 4

最后修改的时间: 2009-10-26 14:57:25 +0800 (星期一, 2009-10-26)

 

Basic Usage

Getting Data into Your Repository

The svn import command is a quick way to copy an unversioned tree of files into a repository, creating intermediate directories as necessary.

For Example: If you want to add the project in D:\code\java\eclipse\Sample to the root directory of your repository like /Sample , the command line should be:

svn import D:\code\java\eclipse\Sample svn://localhost/Sample -m "initial import"

By this command, all files and directory in D:\code\java\eclipse\Sample, will be added into repository, means project Sample is under version control.

Note:

If you config your passwd file a user with a password, and use the user to execute the above command, you should add arguments like --username ivar --password ivar to the end of the command.

You can learn more about the command svn import by typing svn help import, other commands will be the same.

 

Initial Checkout

Most of the time, you will start using a Subversion repository by doing a checkout of your project. Checking out a repository creates a “working copy” of it on your local machine.

For example, if you want to create a copy of URL svn://localhost/Sample to D:\work\Sample, the command line should be:

svn checkout svn://localhost/Sample D:\work\Sample --username ivar –password ivar

If the command is executed successfully, you will find that D:\work\Sample contains all the copies of files in svn://localhost/Sample.

 

See an overview of your changes

If you run svn status at the top of your working copy with no arguments, it will detect all file and tree changes you've made. Here are a few examples of the most common status codes that svn status can return. (Note that the text following # is not actually printed by svn status.)

?       scratch.c           # file is not under version control

A       stuff/loot/bloo.h   # file is scheduled for addition

C       stuff/loot/lump.c   # file has textual conflicts from an update

D       stuff/fish.c        # file is scheduled for deletion

M       bar.c               # bar.c has local modifications

 

Commit Your Changes

The svn commit command sends all of your changes to the repository. When you commit a change, you need to supply a log message describing your change. Your log message will be attached to the new revision you create. If your log message is brief, you may wish to supply it on the command line using the --message (-m) option:

$ svn commit -m "Corrected number of cheese slices."

Sending        sandwich.txt

Transmitting file data .

Committed revision 3.

 

Generating a List of Historical Changes

To find information about the history of a file or directory, use the svn log command. svn log will provide you with a record of who made changes to a file or directory, at what revision it changed, the time and date of that revision, and—if it was provided—the log message that accompanied the commit:

$ svn log

---------------------------------------------------------------------

r3 | sally | 2008-05-15 23:09:28 -0500 (Thu, 15 May 2008) | 1 line

Added include lines and corrected # of cheese slices.

---------------------------------------------------------------------

r2 | harry | 2008-05-14 18:43:15 -0500 (Wed, 14 May 2008) | 1 line

Added main() methods.

---------------------------------------------------------------------

r1 | sally | 2008-05-10 19:50:31 -0500 (Sat, 10 May 2008) | 1 line

Initial import

---------------------------------------------------------------------

 

svn log also takes a --quiet (-q) option, which suppresses the body of the log message. When combined with --verbose (-v), it gives just the names of the changed files.

 

Discarding your changes

If you decide that you want to throw out your changes and start your edits again (whether this occurs after a conflict or anytime), just revert your changes:

$ svn revert sandwich.txt

Reverted 'sandwich.txt'

$ ls sandwich.*

sandwich.txt