Are you using the Perl SVN::Notify module to generate your Subversion commit notification emails yet? If not, go install it, and try out svnnotify. It generates very nice-looking text or HTML-formatted emails, and it has loads of options to make it do just what you want. Place as many svnnotify commands as you like in your Subversion post-commit hook script, and off you go.

Unfortunately, with a large number of developers and many different projects in your repository, your post-commit script may start to look like this:

svnnotify -r $2 -d -P "SVN Commit " -O -H HTML::ColorDiff -p $1 -t dev@company.com
svnnotify -r $2 -H  Mirror::Rsync -p $1 --rsync-host devserver.company.com \
    --to /usr/local/www/htdocs --rsync-delete=yes
svnnotify -r $2 -d -P "SVN Tag Creation " -O -H HTML::ColorDiff -p $1 \
    -x builder@company.com=/tags
svnnotify -r $2 -d -P "SVN Branch Creation " -O -H HTML::ColorDiff -p $1 \
    -x builder@company.com=/branches
svnnotify -r $2 -d -P "SVN Vendor Drop " -O -H HTML::ColorDiff -p $1 \
    -x vendormgr@company.com=/vendor
svnnotify -r $2 -d -P "ClientA Special Version Commit " -O -H HTML::ColorDiff \
    -p $1 -x dev@clientA.com=/branches/clientA

Yikes -that’s bound to keep any Subversion administrator up nights! However, help is on the way from Perl developer John Peacock.

John has created a nice wrapper around SVN::Notify named SVN::Notify::Config. This Perl module transforms the mess of command lines above to a cleaner, easily-editable form using YAML to express the desired svnnotify options.

The equivalent post-commit hook using SVN::Notify::Config is now:

#!/usr/bin/perl -MSVN::Notify::Config=$0
 --- #YAML:1.0
 '':
   PATH: "/usr/bin:/usr/local/bin"
 '/':
   handler: HTML::ColorDiff
   with-diff:
   no-first-line:
   subject-prefix: "SVN Commit "
   to: dev@company.com
 '/':
   handler: Mirror::Rsync
   to: /usr/local/www/htdocs
   rsync-host: devserver.company.com
   rsync-delete: yes
 '/tags':
   handler: HTML::ColorDiff
   with-diff:
   no-first-line:
   subject-prefix: "SVN Tag Creation "
   to: builder@company.com
 '/branches':
   handler: HTML::ColorDiff
   with-diff:
   no-first-line:
   subject-prefix: "SVN Branch Creation "
   to: builder@company.com
 '/vendor':
   handler: HTML::ColorDiff
   with-diff:
   no-first-line:
   subject-prefix: "SVN Vendor Drop "
   to: vendormgr@company.com
 '/branches/clientA':
   handler: HTML::ColorDiff
   with-diff:
   no-first-line:
   subject-prefix: "ClientA Special Version Commit "
   to: dev@clientA.com

That’s a lot more readable, and I expect it will be easier to maintain, even though there are more lines in the file. I’m still boning up on the YAML syntax and how this module uses it, so there may be some optimizations to be made. Feel free to send corrections!

The other thing I like about using YAML this way is it lends itself well to hooking into a notification management web interface, and that makes it even easier to keep those emails flowing where they should.

Keep in touch,
Greg

I participated in a CM Crossroads webinar on Wednesday that discussed new features appearing in Subversion 1.5. There are some excellent bits on the way, and the release is currently predicted for Q1 2008.

First and foremost, the new release will support Merge Tracking. This means that you will no longer have to manually keep track of which merges you’ve applied and which ones you’ve intentionally skipped. Recording this information becomes harder and harder the longer a branch lives.

The new Merge Tracking feature will also support querying of the merge history. I hope this functionality is similar to the cleartool findmerge command from IBM/Rational ClearCase. I began using CC in the early ‘9os, and the findmerge command seemed like magic at the time. It was a huge time-saver when preparing complicated releases based on the work of multiple developers.

Subversion 1.5 also optionally launches a graphical resolver when a conflict is detected within a merge operation over a large number of files. This allows you to manage conflicts as they happen instead of waiting until the very end of the operation to go back and manually edit the markers within each problematic file.

WebDAV write-thru proxies is an interesting new feature for SaaS providers (i.e. SourceHosting.net!). It allows us to set up a number of repository proxies at various locations around the globe. Users point to the repository closest to them and perform read-only operations on it. When a write operation is performed, the proxy forwards the request to the master repository. Changes are mirrored back to the proxy for future read-only operations. I personally look forward to experimenting with this feature to increase performance for our world-wide user base.

One final important change also concerns service providers or those of you who operate your own repositories. If you use the FSFS repository format, it stores all revision files in one monolithic directory. The more revisions you have in your repository, the slower certain repository operations work. UNIX filesystems perform much better as trees of directories and files instead of one enormous directory with thousands of files in it. Subversion 1.5 supports a hierarchical directory tree repository format, removing the performance bottleneck as the number of revisions grows.

I hope that gives you a taste of what’s arriving in Subversion in 2008. For the latest details, keep an eye on the Subversion project status page.

Keep in touch,
Greg