The Fugue

I love it when someone else writes what I’ve been meaning to write, so I don’t have to write it.

This article covers the reasons why I switched from mercurial to git, about as well as he could possibly hope to without consulting me, reading my mind, or being me. It’s a bit creepy.

He explains it very well (probably better than I would) and has more insight into the technical details than I do.

While we’re on the subject, you should all go read git for computer scientists so you can think like a git. If you already have a CS background, it’s quite painless I assure you.

The problem: Ardour uses Subversion, but I’m addicted to distributed revision
control systems. Actually, svn and I would have got along just fine if it
weren’t for svn merge. What an embarrasment for svn lovers everywhere! You
have to manually dig up which revisions to merge with. svn doesn’t keep track
of what’s already been merged so you also have to be careful not to merge the
same stuff twice. To add insult to injury, you have to type those full, long
svn URLs too. So what would be darcs pull becomes something like:

svn merge -r 536:543 \
  svn+ssh://ardoursvn@ardour.org/ardour2/trunk \
  svn+ssh://ardoursvn@ardour.org/ardour2/branches/region-plugins

Ick.

So I started investigating gateways from svn to darcs or git, either of which I would have happily used. Tailor seems like a good way to do it, but I had a hard time wrapping my head around the bidirectional setup. git-svnimport looks promising for a git solution, but before I got a chance to try it I looked at svk. svk is perfect for this situation.

If you’re not aware, svk is a distributed RCS front-end to svn. I knew about it
before but had always thought of it as a hack marrying the worst of two worlds.
Since my last look it has improved considerably, and my approach has also
changed as I’m now looking at it asa developer in an svn project, not the guy
setting up a repo and wondering which system to use.

svk is mostly like svn, except you mirror the repo on your hard disk and can do
disconnected development. To be honest I haven’t looked at the truly
distributed aspects of svk (if they exist), but rather I have focused on what I
needed: disconnected operation with the ability to create local branches with
easy merging, and work with the existing svn repo. svk does these things very
well.

Here’s my new workflow, from the point of installing svk:

# setup
svk mirror svn+ssh://ardoursvn@ardour.org/ardour2 //mirror/ardour2
svk sync //mirror/ardour2
cd ~/src
svk co //mirror/ardour2

# branch
cd ardour2
svk cp //mirror/ardour2 //local/region-plugins
svk switch //local/region-plugins

# edit stuff then check in
svk ci

# merge in trunk changes to my branch
svk pull

# merge my branch back into the trunk
svk push

Learn more about svk by reading “SVK, A Visual Guide“, Jonathan Weiss’ blog entry, and the Bieber Labs tutorial.

OS X has this nifty utility called FileMerge which is far and away the best way
to merge differing files that I have ever seen. Yes, that includes vimdiff,
although a sufficiently large gvimdiff is pretty good too. If you give it a
try, don’t give up saying “too much mousing” until you’ve explored the (mostly
hidden) keyboard acceleration. I found sensible accelerators for every function
I hoped for.

Bruno De Fraine has
gifted us with a set of bash
scripts to use FileMerge as
Subversion’s --diff-cmd and --diff3-cmd. This means when you have a
conflict in Subversion you can merge with FileMerge. Along with the [helpers]
section in ~/.subversion/config you can be in FileMerge/SVN paradise.

I intend to figure out how to get this working with darcs soon. Actually I’ve
found some pages about it that don’t seem to work with my current version of
darcs. When I get more HDD space I can install that silly Haskell compiler and
upgrade, then I will report if it works.