Item Description: Distributed / offline version control

Review Synopsis: Developing software with a local copy of your version control repositories

I first heard about SVK at a talk given by Chia-Liang Kao at a couple of years ago. Being something of a version control freak (author of VCS::Lite::Repository), naturally I was interested. It was a good talk, and interesting to see what could be done with version control, with some interesting real world problems.

I'd filed my thoughts under "something I should look at when I get a mo". Not being a jet set, or a long distance commuter, I didn't have any immediate need for SVK.

Now, with the Birmingham YAPC::EU imminent, I will be needing to venture out of my home hacking den, and would quite like to continue working on some CPAN module development. Coincidentally, I have moved my subversion repository for my CPAN modules to a hosted box, and gotten webdav over HTTP working.

To date I have been working with multiple checkouts in different directories, getting to know svn quite well. Now I realise that this is a mess. Time to look at SVK.

Despite what some have said, I didn't find it at all difficult to install - one command for Debian:

apt-get install svk

Granted you could build it from CPAN. You need the svn perl bindings for this to work though, but apt deals with the dependency nicely. I gather that there is a Redhat RPM available, and Windows binaries.

Then there was the grokking of the tutorials, which had changed since I first looked. In the mean time, being fully up to speed with svn helped, as the svk commands are a superset of the svn commands.

Once you have SVK installed, you need to issue the following command once, for your user account:

svk depotmap --init

This sets up your anonymous "depot", a container for repositories which can be standalone, or can mirror remote svn repositories (or indeed cvs and other version control repositories).

svk mirror // svk sync //

These are all you need to do to get started, hooking to an existing hosted repository. The first command creates an association between the remote repository, and its mirror that lives inside the depot. The second command is used to pull down the whole remote repository (though you can specify a subdirectory if this is all you are ever going to want), including the revision history.

That's all you need to do online. Everything else now works with your local mirror on your hard drive. All the checking out, merging etc. can be done without an Internet connection. Obviously you need a link when you want to receive other updates, or to publish your changes. There's even a -p option that lets you work with remote repositories where you don't have commit rights (you submit patches).

In my opinion, SVK rocks! This review is merely scratching the surface, and readers are referred to the full documentation:

Update: local branches

xdg is perfectly correct that you want to create a local branch, in order to do your work offline. Your mirror repository is just that; you can't have extra work committed to this, which is not in the remote repository. And, svk will make sure that this is so, blocking commits to the mirror if you are not online.

See xdg's reply below for the commands to create a new local branch and check out from it.

When you are connected and want to release your work, use the following command:

svk smerge --baseless --incremental --verbatim //local/ //foo.b +ar/

The --incremental and --verbatim options do multiple commits, merging in the change history from your branch; omit these if you are happy with a single changeset and commit for everything. You need --baseless the first time you merge, as at this point, SVK has no common ancestor for the merge process.