Subversion – A Scoop of it!

Subversion, famously known as SVN in the open source world, is a vesrion control and management system. It forms a vital part of software development, where the code development is a continuous process and hence results in frequent change of small part of the code. Thus, it is veri important to keep track of the change so that the various modules and components of the project are in sync with one another.

SVN serves three main purposes:

  1. Tracks the changes done by individual contributors of the project and produces a new version with each release.
  2. Helps in collaborative development of the project, where many developers can work over a stable main code.
  3. The modifications done by one developer can be easily tracked by others and hence they can modify their work to keep themselves in sync with the main trunk of the project.
  4. It allows branching of a main project, where the branches run parallely with the main project but still keeps in sync with those components which it has got from the main trunk.

How does SVN do this ?

SVN consist of a main repository in a central server location which can be accessed from the individual clients who are contributors to the project. Each individual developer has a working copy of the project code, which he has got from the main repos and ensures it is updated with the changes made to the repos code. His local working copy is where he makes his own changes as well as where he adds his own new codes. Before he starts his work, it is his responsibility to update his working copy so that it is in sync with the main project code. Once he has the updated working copy, he starts his work. When he has finished his work, he adds these to the repository. At this point, SVN checks with the existing version of the project. If both are same, i.e. the developer hasn’t made any changes with respect to the repository, then he is intimated that there is nothing to be updated. If he has modified or added some files, then his files are marked for addition to the repository trunk. When he ‘commits’ his changes, the files are added/modified as per his working copy, creating a new version of the project code. The SVN creates a new version in the repository, which is one more than the previous version. The term version is known as ‘Revision’ in SVN. Thus when another developer checks the his working copy with the repos, SVN finds out that the code has changes and ask him to update his local copy so that it is aware of the changes made. Then the second person updates his working copy and continues with his work.

A peculiar case that can occur at odd times is, two persons making change in the current version at the same time. That is, they start with the same version/revision, make their own changed and commit. Whoever has comited first, updates the repos and hence a new version/revision is made. When the latter commit is obtained, the second persons working code is obscure and hence the SVN warns him that some one has made changes since he updated his code last time. Then he checks with the current code, what are the changed made. If the changes made don’t affect his code, he goes on with a new version. Else, he has to get the new copy and make changes in it to incorporate his work. He can also accept a part of the changes made, if he finds them to be correct.

To make things clear here is a small example. Consider that a repos named sandbox to be created and a local working copy is named as sbox. The repos is accessed by https at Here is a simple step-by-step to create and manage with SVN:

1. Create a local copy of svn for the corresponding repos

$svn co sbox

2. Having a local working copy been created as above, we check the status of the svn as follows,

$svn status

3. Now, after creating our new file ‘ReadMe’, we add it to the repos.

$svn add ReadMe

4. Commit the changes made to the local copy, so that it is updated in the main trunk

$svn commit -m ‘First change’

5. Check the svn log for more info,

$svn log ReadMe

6. To check whether there is any difference between working copy and local copy, use dif command with svn,

$svn diff

This will give those codes in the working copy that differs with the current active revision in the repos.

7. When a conflict occurs with the current version and the local copy, to make the svn accept the corrected loca copy, issue resolve command as follows,

$svn resolved ReadMe

8. To delete a file in the current version, isse a remove command..

$svn remove ReadMe

These are the basic commands for common svn operation. Manual/Tutorial for svn, called as the Subversion Book, is available at

Enjoy svn, enjoy collaborative development! 🙂


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s