New in Subversion 1.7: svnrdump and improved diffs

  

 Email Article  

Tweet  

  

Subversion (SVN) is the world's most widely used source code control system (SCCS), but even if you're familiar with Subversion, you might not know about two useful enhancements in the 1.7 release: svnrdump, for remote, user-level administration, and improved diffs, a vital convenience for front-line developers.

Though it's a year old, Subversion 1.7 is not standard with all operating systems yet. CentOS 6.3, for instance, comes with Subversion 1.6.11 standard. Updating to 1.7 is a bit tricky for technical reasons: the server side of Subversion depends on an older release of the Neon library, and installation of only the client side involves its own difficulties. Complete directions for 1.7 installation appear here. The crucial element is an RPM for Subversion 1.7.

If your desktop is an older version of Ubuntu, you might need to run the following commands to get up-to-date before you try out the new features:

echo "deb http://opensource.wandisco.com/ubuntu lucid svn17" | sudo tee /etc/apt/sources.list.d/svn.list
sudo wget -q http://opensource.wandisco.com/wandisco-debian.gpg -O- | sudo apt-key add -
sudo apt-get update
sudo apt-get dist-upgrade

Network-savvy administrative maintenance

To programmers, an SVN repository is like a trusted bank, except more important; they need complete confidence that the source code they check in will be safe until the next time they need it. An essential part of such a guarantee is routine use of the svnadmin utility to save, repair, restore, and otherwise manage repository images.

To use svnadmin, you need to be the administrator on the repository host. You can see the fragility this entails: disaster recovery is dependent on a single (logical) user, operating on a single host.

The svnrdump utility addresses that issue. With svnrdump, any authorized user can "serialize" or dump a repository image to a backup that's local to the user, and later restore the repository, either to a new host or to the existing one.

Svnrdump is built on top of standard SVN replay tools, and respects SVN's built-in security. That means that remote users can only svnrdump the repository items they are authorized to access; svnrdump is not a loophole in SVN's security. This is both good and bad; it can easily happen, for instance, that you as a remote user think you have a backup copy of a particular repository, when you actually have a backup of only the part of it you've been authorized to view. Such security consequences underline the importance not only of backing up a repository, but also testing the backup by attempting to restore it. In far too many cases, organizations have gone to great effort to create backups, then learn only after an incident that the backups are flawed to the point of uselessness.

Svnrdump's construction on existing components means that you might be closer to using it than you realize. Any SVN server at version 1.4 or above supports svnrdump use from a client installation at 1.7. While your desktop might well require an update to take advantage of svnrdump, your server is most likely ready without any modification.

How do you use svnrdump? A typical invocation might be svnrdump dump http://svn.apachr.org/repos/asf/subversion -r 836599 > subversion.dump. This command creates in the local filesystem a binary image, subversion.dump, that captures all of revision 836599 of the source code to Subversion itself. Note that there's nothing particularly special about 836599; it was just convenient for me to show how to use svnrdump. The freely available Red Bean online book "Version Control with Subversion" details all of svnrdump's options. A more extended explanation called "Migrating Repository Data Elsewhere" discusses usage and best practices. As you'll read there, a typical complement to the previous command is

  svnadmin create /var/some_dir/new_subversion
  svnadmin load /var/some_dir/new_subversion < subversion.dump

This creates a new new_subversion repository on the local machine, with the content of revision 836599.

As you work with svnrdump, recognize that it is intended only for remote administration; it's not a suitable basis for distributed or networked repository use by front-line coders. If you have a need for a distributed version control system (DVCS) or distributed source code managements system (DSCM), you'll probably want to consider one of the newer and more complex systems such as Git.

diff upgraded

Release 1.7 also brings an enhancement to the svn diff command; textual changes appear in unidiff format now. Unified format, or unidiff, is more descriptive and occasionally more compact than the older and perhaps more familiar "context" format. Unidiff text makes good input to the widely used patch utility, and is a common format in many software projects for patch submissions.

An example helps illustrate the difference between context and unified diff formats. I ran diff against two versions of the source for this article, in two different formats. As a context diff, I see

  100,103d99
  < <p>An example helps illustrate the difference between context and unified
  <    diff formats:  I diffed two versions of the source for
  <    this article 
  < 

In unified format, on the other hand, I have

  --- draft.html	2012-08-29 21:27:04.707331528 +0000
  +++ draft.html.0	2012-08-29 21:25:19.866269792 +0000
  @@ -97,10 +97,6 @@
      familiar "context" format. Unidiff makes good input to <code>patch</code>,
      and is a common format in many software projects for patch submissions.

  -<p>An example helps illustrate the difference between context and unified
  -   diff formats:  I <code>diff</code>ed two versions of the source for
  -   this article 
  -

Unidiff isn't nearly as exciting as svnrdump or 1.7's performance improvements. If you need to submit unidiff patches, though, this one change can significantly streamline your work.

Other features

Unidiff and svnrdump aren't the only useful new features you'll find in the 1.7 release. Its improved use of HTTPv2, for instance, has the potential to boost performance considerably, especially in combination with improvements in the internal implementation of SVN.

While Subversion looks like a mature project – the project began in 2000 – development continues. Some of the implementation enhancements in 1.7 have their greatest value as a basis for changes planned for future releases, including offline commits, "shelving," "newmerge," and automated commit and update.

You can read about 1.7's other advantages in the WANdisco blog and this write-up from Dr. Dobb's. For the majority of readers, though, I suspect svnrdump and svndiff by themselves make a compelling argument for upgrade.