This week I was attending a CI training course about svn. Here I'd like to share what I have learnt. As I am an absolutely green bird to svn, this post only covers those most common usages.
(1) Create a repository
Given that we already have a project with a directory structure as below:
my-project
|____branches
|____tags
|____trunk
| |____etc
| | |____conf.txt
| |____source.txt
Now we want to create a svn repository to accomodate this project, first we need to initialize an empty repository:
svnadmin create path/to/svn-repository
(2) Run SVN server
svnserve -d -r path/to/svn-repository
The "-d" option tells svn server to run as a deamon, and the "-r" option tells the server the location of our repository, now we are able to access our repository using URL: svn://localhost. In order to allow any anonymous user to have both read and write permission(this may not be a good practice, we do so just for convenience), we can modify the configuration file named svnserve.conf located under the repository's conf subfolder, comment in these two lines:
anon-access = write auth-access = write
Now we are able to read and write to the repository without providing a user account.
(3) Import a project
Once the repository has been created, the next step is to import our project into the repository:
svn import path/to/my-project svn://localhost
An svn repository for our project has been created, you may take a look at our newly imported project in the repository with:
svn list svn://localhost branches/ tags/ trunk/
As we can see, the directory structure in the repository is exactly the same as the original project.
(3) Checkout the code
We don't have to pay much attention to our original project any more as svn repository already contains the whole project, then if someone wants to make a working copy, she/he can make a checkout:
svn checkout svn://localhost/trunk working-trunk
The command above checks out the trunk folder to working-trunk, other folders can also be checked out using the correspond subfolder name, or the whole project can be checked out with no folder names.
(4) Make some change
Now switch to working-trunk and make your own change, you can modify a file directly, or add a new file using "svn add filename", delete a file using "svn delete filename", and rename a file using "svn rename old-filename new file-name".
(5) Checkin the changed code
Once we are confident enough to publish our change to the repository, we can check in our code. But before we check in our code, we need to pull the latest code from repository given that others may have checked in their code, we can use the command below to update our own working copy:
svn update
If we are lucky as there's no conflict between our own change and those pulled from the repository, we can check in our code directly:
svn commit -m "description of my change"
(6) Manage merging
In step (5), we were praying our own change doesn't overlap with the changes made by others, but there are times our change do overlap with others' code and conflict occurs when someone modified the same lines of code as ourselves do, under such circumstances we need to merge the conflict manually. If we try to update our own working copy when there is conflict, we will get the following information:
Conflict discovered in 'source.txt'.
Select: (p) postpone, (df) diff-full, (e) edit,
(mc) mine-conflict, (tc) theirs-conflict,
(s) show all options:
There are sevral options to choose, with "postpone" to skip editing the conflict for the time being, "edit" to nevigate us to edit the conflict right now etc.. If we choose "(p)postpone", the conflict will remain there for later resovle, and our conflicting file(source.txt) will be marked in its content as having conflict:
............
<<<<<<< .mine
this is modified by me
=======
this is modified by another person
>>>>>>> .r6
............
The content between "<<<<<<<<" and "=======" shows our own change while the content between "======" and ">>>>>>" shows changes make by others. Now if we want to keep both changes, what we can do is to edit the conficting file as below:
.............
this is modified by me
this is modified by another person
.............
and then tell svn the file has been merged by using:
svn resolve --accept=working source.txt
next, don't forget to commit the merge:
svn commit -m "merge source.txt"
(7) Branching
svn uses "svn copy" to create branches, chances are that we are at some stage of trunk development and we want to introduce a new feature without influencing the trunk, making a new branch for that feature is a good choice. To create a branch in svn:
svn copy svn://localhost/trunk svn://localhost/branches/new-feature -m "create a new branch named new-feature"
Now we can check out the new branch and implement new feature in it:
svn checkout svn://localhost/branches/new-feature
(8) Tagging
Tagging in svn is implemented in the same way as branching, yet tagging differs from branching is that tagging usually serves as a purpose to create a stable version from trunk.
