Configuration Management Using Subversion

About Subversion

Subversion (SVN) is a open source version control system. In a 2007 report by Forrester Research, Subversion was recognized as the sole leader in the Standalone Software Configuration Management (SCM) category and strong performer in the Software Configuration and Change Management (SCCM) category.

Filesystem

The Subversion filesystem is described as a "three dimensional" filesystem. Since most representations of a directory tree (e.g tree view) are two dimensional, the added dimension is that of revisions.

Properties

Properties are used in two different places in the Subversion filesystem. The first is on filesystem entries (i.e., files and directories). These are versioned just like other changes to the filesystem. Users can add any property they wish, and the Subversion client uses a set of properties, which it prefixes with 'svn:'.

Locking versus Merging

In a file locking system, the developer locks a versioned file when beginning to make changes. While the file is locked, no other developer will be allowed to make any changes. Then, when the developer has finished, the changed file can be committed back into the repository and the file can be unlocked.

The upside to file locking is that it enforces very organized division of work, in order to minimize the number of times where two developers need to modify the same source file or section simultaneously. It can also work better than merging when working with files that are not easily merged automatically, such as graphics, or files in proprietary binary formats. On the other hand, locking can disrupt development if progress is blocked by two developers competing to work on the same file. The problem can be magnified further if one of those developers forgets to unlock the file when finished. In general, locking scales very poorly and is unworkable for broad use by projects involving more than a few people.

The second method for handling collision avoidance/resolution is the use of automatic or semi-automatic file merges. In this model, developers can modify files in their working copies of the repository without regard for what others are doing. Then, once the developers have finished making their changes, they can commit those changes, and the version control system will check to see if there are any collisions caused by two people simultaneously editing a file. In many cases, the system will automatically merge two files together; but if it can't, most systems will provide the developer making the commit with information about the conflicted area, to allow the developer to merge the changes by hand.

Branching and tagging

A new branch or tag is created with the 'svn copy' command. Subversion does not create an entire new file in the repository with its copy. Instead, the old and new files are linked together internally and the history is preserved for both. The copied files take up only a little extra room in the repository because Subversion saves only the differences from the original files.

All the files in each branch maintain the history of the file up to the point of the copy, plus any changes made since. Changes can be 'merged' back into the trunk or between branches.

Visualization of very simple Subversion project.

• Branches are just copies of the main trunk
  
  
  • Make changes in the copy
    
  • Merge the changes back to the main trunk
    
• Tags are copies which are never changed
  
  
  • Might not even be necessary if you simply record the global revision number that built your product

Projects in my Organization (click on picture for a clear view)