Subversion 1.7 released: just one .svn directory per working copy

Yesterday saw the 1.7 release of Subversion, the widely used open source version control system. It is a significant release with many new features, bug-fixes and performance improvements, and I suggest reading the release notes or complete change log. One thing to highlight is that the default working copy metadata storage is now a single sqlite database per working copy, rather than a .svn direction containing metadata in sub-directory.

I upgraded my TortoiseSVN, which is already updated to 1.7, and tried upgrading one of my own projects. Here is the .svn folder before the upgrade:

image

and after

image

Those pesky .svn folders can be a nuisance so this is a welcome change, although there is a downside as the release notes warn:

It is not safe to copy an SQLite file while it’s being accessed via the SQLite libraries. Consequently, duplicating a working copy (using tar, cp, or rsync) that is being accessed by a Subversion process is not supported for Subversion 1.7 working copies, and may cause the duplicate (new) working copy to be created corrupted.

Subversion is less fashionable since the advent of distributed version control systems like git and mercurial; though for corporate development Subversion remains popular because a centralised system is easier to control.

WANdisco’s Jessica Thornsby has a helpful post on the new 1.7 features more details on the benefits of the new working copy metadata managements system.

VN:F [1.9.18_1163]
Rate this post
Rating: 0.0/10 (0 votes cast)

Related posts:

  1. Rumblings in the Subversion community as WANdisco claims to be “shaking it up”
  2. What’s new in Subversion 1.5
  3. Single sign-on from Active Directory to Windows Azure: big feature, still challenging
  4. Restoring an old Small Business Server 2008 backup: beware expired Active Directory
  5. ThoughtWorks Mingle is released

4 comments to Subversion 1.7 released: just one .svn directory per working copy