What is New in Subversion 1.5



As the saying goes Software never die until the last user die, every developer in a software project work towards improving the state of the software project. The team is engaged in adding new features, enhancing existing functionalities and fixing bugs. The Subversion project is not an exception. The Subversion development team is constantly working towards producing the good quality version control system, by defining standards for versioning methodologies.

In this article, we'll take a tour on various new features added in Subversion 1.5 release. It is not a complete list, but it gives an overview of important features the users have been waiting for so long. In this article, we cover few new features added in Subversion 1.5 release. It also provide a list of other features and improvements added in this release. However, we do not cover various bugs that are fixed in this release.

Merge Tracking

In pre 1.5 releases, merge is a utility outside of Subversion. The users are responsible to keep track of what to merge and record the merge information on the resulting revision. It is completely a manual process, the user should be intelligent to keep track of the merges. The following diagram illustrates the problem that exists in pre 1.5 releases.


In the above diagram, the user might face an error when he attempts to merge the revisions, revision 11 through revision 17, since revision 11 and revision 13 has been merged to the branch in the past.

This is one of use case addressed by the merge tracking feature in 1.5 release. It automatically handle the situations such a duplicate merges. It records the revisions that exists on a given path, and provides a traceability of what path made it to which revision. By automating the merging process, the information stored in repository is reliable. It is vital to certain industries with high demands on product safety.

It supports cherry picking changesets and it documents what changesets have been merged to where. It also records the merge done outside of the merge tool, probably using a manual process. The merge history is consistently recorded. The svn mergeinfo command answers various merge questions, what changes have been merged to any branch and what changes are eligible for merging from any source path.

Change Lists

At any given point in time, the developer may be working on multiple issues involving multiple source code files. The changelist feature gives the developer a flexibility to associate set of files with human readable changelist name. He can refer to these set of files using the changelist name.

For instance, the developer can create a changelist pointing to 10 source code files. Whenever he want to commit the changes in any of these files in the repository, he can use svn commit –changelist changelist_name command. This command will check if there are any changes in those 10 files and include the changed files for committing in the repository.  The user can manage changelists using svn changelist subcommand.

Sparse Checkouts

In Subversion 1.5 release, a facility is added to effect the operation for files and directories to a certain level. The --depth option is added to most for Subversion commands. This option is similar to --non-recursive (-N) and --recursive (-R) and improves upon these options making these options obsolete.

For example, the command svn checkout repos_url wc_path --depth files will checkout immediate target of the operation and all of its immediate file children. Similarly, the command svn checkout repos_url wc_path --depth immediates will checkout immediate target of the operation and all immediate files and directories. The directory children will themselves be empty.

Interactive Conflict Resolution

The conflicts may occur during following operations: merge, update and switch. In 1.5 release, an interactive conflict handling interface is provided for the user to fix the conflict instantly. The user can configure the default behavior during conflict resolution process.

The following table illustrates the list of options among which the user an choose while resolving the conflict:

$ svn merge proto://hostname/svn/branches/B1 .
Conflict discovered in 'B1/greek/iota'.
Select: (p)ostpone, (d)iff, (e)dit, (h)elp for more options : h
  (p)ostpone - mark the conflict to be resolved later
  (d)iff     - show all changes made to merged file
  (e)dit     - change merged file in an editor
  (r)esolved - accept merged version of file
  (m)ine     - accept my version of file
  (t)heirs   - accept repository's version of file
  (l)aunch   - use third-party tool to resolve conflict
  (h)elp     - show this list

  Select: (p)ostpone, (d)iff, (e)dit, (h)elp for more options :


FSFS Sharding

Before Subversion 1.5 release, the FSFS repositories contain files that describe the changes made in a single revision, and files that contain revision properties associated with a single revision. These files are kept in two directories, one for each type. As new revisions are committed to the repository, Subversion adds more files in these directories -- over time, the number of files can grow to quite large.

In Subversion 1.5 release, the FSFS backed repositories are created by slightly modified layout.  The content of these directories are sharded, or in other words, scattered across several subdirectories. This can greatly reduce the time it takes the system to locate any one of these files, and therefore increases the overall performance of Subversion when reading from the repository.

Other key features and improvements

In Subversion 1.5 release, few more features have been added. The functionality of existing features have been improved dramatically. The key features that are not covered in this article are as follows.

WebDAV transparent write-thru proxies
Cyrus SASL support for ra_svn and svnserve

The substantial improvements for existing features are as follows:
 
Copy/move improvements
Externals improvements
Cancellation improvements
Easier to try out ra_serf DAV access module
Lots of API improvements and miscellaneous bug fixes

Conclusion

So far, you have been using Subversion as a standard for Version control system. After Subversion 1.5 release, you would be surprised to see the comfortableness it provides for any developer while working on any software project. The Subversion version control system can be downloaded from following websites:

http://subversion.tigris.org
http://open.collab.net

About the Author

By: Bhuvaneswaran A. The author is currently employed in CollabNet working for their Operations Engineering group. He is an Official Member of Ubuntu Linux and a Partial Committer for Subversion project.

The article is published in Linux For You Magazine May 2008 Edition. The article in PDF format can be downloaded from here.