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.