Just when you thought version control couldn’t get any cooler (and we all think it’s cool, right??), along comes SVK. SVK is a distributed version control system (a la Bitkeeper) written by Chia-liang Kao. The tool allows you to mirror existing remote repositories, create branches on your machine, work on these branches locally, and when you are ready, merge them back into your mirrored trunk, which transparently updates the remote repository.

I have spent only a small amount of time with SVK, and have limited knowledge thus far on it’s capabilities. However, in the couple of days that I have been playing around with it, I prefer it over straight Subversion for a number of reasons including:

1. Full local repository on my machine – I can commit to save, back out, or merge code as if I was sitting at my desk, even in the most remote location.
2. No more long URLs – Once you mirror the repository, svk aliases your repository to something short and more manageable for those of us who hate typing.
3. Incremental synchronization of mirrored repositories. Depending on the size of your repository the initial synchronization can take a while. Subsequent syncs are very fast though
4. Repeated merge support – SVK implements the ‘star-merge’ algorithm introduced in arch – and does it without being as cryptic. It keeps track of merges that have already been done from branch to branch and eliminates the need to skip synchronizations of the trunk to the development branch when merging your changes back into the main line. So, you can synch your mirrored branch, merge the changes into your local branch, and keep working. When you merge your changes back, the tool knows which revisions have been merged from the destination and doesn’t merge them – reducing a load of conflicts and / or manual work in figuring what to exclude.
5. Simple command set – the commands ‘mirror’ Subversions command set. The whole mirroring of the repository and the merge syntax can be intimidating at first, but once you do it a few times it makes complete sense.
6. Lightweight Workareas – SVK does not use the .svn directory in the local workarea. The workarea is very lightweight and does not use the space that the ‘vanilla’ Subversion tool uses.
7. The freedom to walk away knowing that if you don’t have a network connection, you are not dead in the water.

This is the first in a series of articles that will build on one another to show the capabilities of SVK as I learn them. Just in the last couple of days, I’ve done enough to know that it cannot be covered in one article. I hope you enjoy these and stay tuned for Part 2.

Why Distributed Version Control?

The first question people might ask when talking about a tool like SVK is “What does distributed version control get me?”

Well, consider this simple but common scenario. You have a deadline that you have to meet but hate being in the office late at night. You would rather be sitting on your couch watching the latest installment of Mythbusters and cutting code. Or better yet, you would like to leave the office for a bit to get away from interruptions and go to the nearest Starbucks, have a coffee and work there. Unfortunately, you need a connection to the source repository in order to continue your work. In either scenario, your life would be more pleasant being somewhere outside your office, but you need the full source repository in order to perform your work (such as merging or backing out some ideas you were trying out). This might sound a little rediculous, but it is a real scenario, articulated very well in a user story posted to the Subversion development list by by Eric Raymond.

The ideal situation is to be able to mirror the repository (or branch you are working on) on your local machine in a working repository, disconnect from the network, continue your work, and later be able to synchronize your local repository with the production repository. This is what you get with SVK.

Environment Notes

Everything done in this article was done on a Compaq Presario 3000 laptop running SuSE Linux 9.1. There are currently Windows binaries for the SVK tool, however I do most of my work on Linux, and cannot speak to the installation complexity or performance of the tool in the Windows environment.

I have Subversion 1.1.1 installed with both Perl and Python bindings. The Subversion server is running over http/DAV.

The version of SVK I have installed is 0.26.

Notation

Some of the lines in the command are truncated because they are too long. I have used the ‘_’ character as a line continuation character. If you see this character, look at the next line.

Installing SVK

The tool is written in PERL, and consequently is kind of a pain to install. I took me a bit to whittle down the install to the commands you will see below, but I’m one of those people that RTFM as a last resort. You can find detailed install instructions on the SVK Wiki.

First you have to make sure you have the Subversion perl bindings installed. I didn’t and when I initially tried to install SVK from CPAN I had to scour the output when an error occurred to figure this out. However, since I build subversion from the source tarballs I had my last build lying around and was able to type the following to get the bindings installed:

make swig-pl
make install-swig-pl

Once the bindings were installed, installation of SVK turned out to be a matter of installing the latest version (and all of it’s many dependencies) from CPAN with the following command:

perl -MCPAN -e 'install SVK'

This one takes a while, so relax a little bit (after making sure to answer all the prompts to install the many dependencies).

Setting up your local ‘depotmap’

To set up your local repository, type the following command:

svk depotmap --init

This command will check to see if you have a local repository, and if not, prompt you to create it. Answer in the affirmative.

Mirroring your Repository

Mirroring your repository consists of two commands. First, you have to tell SVK what repository path you would like to mirror and what you would like to refer to it locally. The root of your SVK repository is referred to as ‘//’. So to set up a mirror for my web site repository, I do the following:

svk mirror http://subversion.bieberlabs.com/svn/bieberlabs/trunk //bieberlabs/trunk
Committed revision 290.

To ensure that my mirror has indeed been set up, I can use the svk mirror command to list my current mirrors:

svk mirror --list
Path                  Source
===============================================
//bieberlabs/trunk      http://subversion.bieberlabs.com/svn/bieberlabs/trunk

Now that we have a mirror set up, we need to sync our local copy with the remote repository:

svk sync //bieberlabs/trunk
Syncing http://subversion.bieberlabs.com/svn/bieberlabs/trunk
Retrieving log information from 1 to 12
Committed revision 291 from revision 1.
Committed revision 292 from revision 3.
Committed revision 293 from revision 4.
Committed revision 294 from revision 5.
Committed revision 295 from revision 6.
Committed revision 296 from revision 7.
Committed revision 297 from revision 8.
Committed revision 298 from revision 9.
Committed revision 299 from revision 10.
Committed revision 300 from revision 11.
Committed revision 301 from revision 12.

At this point, we can disconnect and go sit on the couch, turn on Cold Case Files, and get some real work done.

Creating a Local Branch

The first thing we want to do before we start working is create a local branch to work in. Doing this is the same as you would do in Subversion, the difference being the paths that you will specify. For this change we will do something simple just to illustrate the point.

svk cp -m "Create local branch for new feature X"  //bieberlabs/trunk //bieberlabs/new-feature-x
Committed revision 302.

Yes, it’s that simple. Since SVK uses the Subversion filesystem to do its work, this operation is very fast. Let’s check to see that we actually have a branch. After all, we’re on the couch and not at our desk, remember?

svk ls //bieberlabs/new-feature-x
network/
qf/
website/

Checking Out Our Development Branch

Let’s check out the web site code and make some changes. I’ve created a directory called svk in my home directory in which I will place all of my workareas. Checking out a workarea is the same as doing it with Subversion. The main difference is that you will be using ‘svk’ as the command and your repository path will be the name you used during the copy (remember the name starting with “//”??):

svk co //bieberlabs/new-feature-x/website
Syncing //bieberlabs/new-feature-x/website (/bieberlabs/new-feature-x/website) _
in /home/rbieber/svk/website to 302.
A   website/wordpress
A   website/wordpress/wp-config.php
A   website/wordpress/wp-rss.php
A   website/wordpress/print.css
A   website/wordpress/styles
A   website/wordpress/styles/panther
A   website/wordpress/styles/panther/style.css

A   website/wordpress/wp-admin/edit-form-comment.php
A   website/wordpress/wp-admin/edit-form.php
A   website/wordpress/wp-admin/import-mt.php
A   website/wordpress/wp.php
A   website/wordpress/wp-feed.php
A   website/new.html
A   website/index.php

… and we’re done for now

So far we have installed SVK, created a mirror of our source repository, synchronized it, created a development branch, and checked it out to a workarea that we can begin coding in. Hopefully, in the work done so far, you can already see SVK’s usefulness. Just wait — it gets bettter. In Part II we’ll actually start using the tool to help us manage our work — all in front of the TV with no network.

Stay tuned.

On to Part II …