Introduction to distributed Version Control System with SVK

VCS such as Subversion or CVS are great but they have a major drawback : when working offline and your server is online, you can’t version your changes until you reach an internet access point.

Here’s where SVK come to your rescue, it’s a distributed (or decentralized as stated on its website) version control system. It works with a under-layer subversion filesystem improved with some useful features, but the interesting part is its ability to play with other VCSs (Subversion, Perforce and CVS) by mirroring them locally and letting you do offline operations on them. Those changes you’ll merge back to remote server when you gain access to an internet connection, but enough with meetings, let’s go to work !

First you need to have a working installation of svk, but I don’t cover this part as it’s specific to each OS, just point you favorite browser to SVK Installation Page and follow the steps corresponding to your environment.

Choose your local layout :

Once you’re done with the installation part, you should start by creating a local svk repository. You have two choices :

  1. A single default repository
  2. Multiple named repository

I choose to go with the first choice, it’s enough hassle to play with multiple remote repositories without having to suffer the pain of searching to which local repository your remote repository belongs. But feel free to choose your way.

Initialize local repository :

svk depotmap --init

This will create the default repository in ~/.svk/local.

As I choose to go with the default repository, it has no explicit name, this assumption will make sense later.

Create an initial layout :

This step is not mandatory, but as I like to keep things as clean as possible, we will create some directories in the default svk repository.

svk mkdir //mirrors -m 'Creating directory for mirrored projects trees'

This line will create a directory called mirrors in root of default svk repository where we’ll put mirrored remote projects trees. Here’s where the no explicit name assumption come to play : the root of default svk repository is access using //, if we had chosen to go with multiple named repository, it’d be /repository_name/.

svk mkdir //local -m 'Create directory for local projects changes'

Let’s create another directory, this time to store local changes, be it local branches of some mirrored projects or simply local projects you want to put under version control.

Mirror your first remote project :

I’ll use a remote subversion repository accessible through Apache’s mod_dav_svn module, but SVK works well with others svn access schemes svn:// or svn+ssh://, without mentioning perforce and cvs.

svk mirror //mirrors/blogmarks -m 'mirror of blogmarks trunk repository'

This line will instruct SVK it has to handle a mirror of the remote repository at in the //mirrors/blogmarks local repository.

Then to checkout the entire tree of the mirrored project in local repository :

svk sync -all


svk sync //mirrors/blogmarks

The last commands start a synchronization between all mirrored remote repository (--all) or a specific one only (//mirrors/blogmarks) and the local repository.
Wait for svk to be done and you’ll have a copy of the remote tree in your local machine.

Make a branch for local work

This part is especially useful for mirrored repositories where you don’t have commit rights, but it’s a good habit for repositories where you have rights access too.

svk cp //mirrors/blogmarks //local/blogmarks -m 'create a local dev branch'

Now your repository would looks like :


Checkout a copy :

Now we’re able to checkout a copy of the new branch to handle our development.

svk co //local/blogmarks BlogMarks

This give us a BlogMarks directory in the current folder which is a working-copy of //local/blogmarks

Now let’s hack your code !!

Commit modifications :

When you’ve implemented you’re next killer feature and want to track the modifications to go on with the next one, in the working-copy directory, issue a :

svk ci -m 'Implements a killer feature'

Merge your changes back to the main remote repository :

If you have write access to the repository, you’ll surely want to send your modifications to the remote server when you gain access to internet. This is another great added feature of SVK.
First be sure to have the latest version for your mirrored project :

svk sync -all


svk sync //mirrors/blogmarks/

Then issue a smerge :

svk smerge -Il //local/blogmarks/ //mirrors/blogmarks

... Follow direction provided on screen by svk ...

Options -Il ensure each modifications you did will be committed individually to the repository (I) using commit log provided when committing to svk (l).

Generate a patch :

In case you don’t have write access to remote repository, perhaps do you want to send developers a patch with your modifications. SVK to the rescue(be sure to re-sync your mirrored repository before generating the patch).

As always there a numerous ways to do that, but I found the Scott Laird ‘s way is really clean, so we’ll go with that.

Create a new directory to handle patch-set :

svk mdir //patchsets

Then copy your project trunk (or branch) :

svk cp //mirrors/blogmarks //patchsets/blogmarks-withkillerfeature

Now merge your change to the patch-set, let’s assume we had changes about our killer feature in changeset 110, 119 and 120 :

svk merge -l -c 110 //local/blogmarks //patchsets/blogmarks-withkillerfeature
svk merge -l -c 119 //local/blogmarks //patchsets/blogmarks-withkillerfeature
svk merge -l -c 120 //local/blogmarks //patchsets/blogmarks-withkillerfeature

Then generate the patch :

svk diff //mirrors/blogmarks/ //patchsets/blogmarks-withkillerfeature

Here it is, a shiny patch ready to be send to developers with write access.

Here it is for this introduction.

Sat, 04 Mar 2006 16:00 Posted in

  1. By Victor Moral 17/09/2007 at 11h40

    Thank you for this post. It’s very useful for me.

Comment Introduction to distributed Version Control System with SVK