SVK – Distributed Version Control – Part II


In our last article, we installed SVK and created our local mirror of our repository. Since the writing of the previous article, we have caught up on a lot of TV by making code changes to our local SVK workarea and using the svk commit command to commit our changes to our local repository. During this time, one of my other personalities has been making code changes to our main repository using straight SVN. This scenario will illustrate keeping your local repository in sync, updating your local branch with changes to your mirrored repository, and merging your local changes back to your mirrored repository when we are finished.


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.

Keeping your mirror current

Some changes have happened in the main repository since we mirrored it, including changes to the main index.php file and a directory removal that was backed out from 8 revisions ago. We have also made some code changes to our local branch, including removing a familypictures directory and modifying the index.php file and now we want to sync our local branch with what is currently in production. To do this we have to update our mirrored repository, requiring a network connection. Once connected to the network, the svk sync command will bring down changes to the main repository to our local mirror just like it did in the first article, only quite a bit faster now since it is only pulling deltas from the last synchronization.

svk sync //bieberlabs/trunk
Retrieving log information from 21 to 23
Committed revision 406 from revision 21.
Committed revision 407 from revision 22.
Committed revision 408 from revision 23.

Now our local mirror is current, so we can disconnect from the network again and go sit in front of the TV.

Keeping your local branch current

To make sure we are changing current code, we need to merge changes made to the main repository to our local branch. In straight SVN, this is done with the SVN merge command and specific revisions must be specified in order to make sure you are merging only changes that were made since your last merge from the trunk. This requires use of the SVN log command to figure out what you merged last in order to get the correct revision range to specify in the merge command.

With SVK, things get a little easier. SVK implements the star merge algorithm first introduced in the arch version control tool. This algorithm figures out what has already been merged from one branch to another, alieviating the need to go through and manually figure out what you need to merge back and forth to the branch.

The first thing we need to do in order to execute a star merge is the equivelent of a –dry-run merge in SVN. Using the -C option of the svk smerge command, we can find out whether there will be any conflicts during our merge to prepare ourselves for any conflict resolution that may have to take place.

svk smerge -C //bieberlabs/trunk //bieberlabs/new-feature-x
Auto-merging (301, 408) /bieberlabs/trunk to
/bieberlabs/new-feature-x (base /bieberlabs/trunk:301).
U   website/wordpress/index.php
A   website/photos
A   website/photos/raytracing
A   website/photos/raytracing/yinyang2.jpg
A   website/photos/raytracing/grapes.jpg
A   website/photos/raytracing/mexico-sunset.jpg
A   website/photos/raytracing/castle.jpg
A   website/photos/raytracing/yyisland.jpg
A   website/photos/jonna
A   website/photos/jonna/jonnaandyairhockey.jpg
A   website/photos/jonna/jonnajake.jpg
A   website/photos/jonna/jonnatattoo.jpg
A   website/photos/jonna/family.jpg
A   website/photos/jonna/ronandandyracing.jpg
A   website/photos/jonna/jonnaboys.jpg
A   website/photos/jonna/ronandbeetle.jpg
A   website/photos/jonna/andysbirthday.jpg
A   website/photos/jonna/jonna.jpg
A   website/photos/jonna/boysandpumpkins.jpg
A   website/photos/jonna/jonnacouch.jpg
A   website/photos/jonna/ronintn.jpg
A   website/photos/kelsi
A   website/photos/kelsi/kelsianddaddy.jpg
A   website/photos/kelsi/cute.jpg
A   website/photos/kelsi/girls1.jpg
A   website/photos/kelsi/kelsiandandrea.jpg
A   website/photos/kelsi/kelsiandandy.jpg
A   website/photos/kelsi/2minutes.jpg
A   website/photos/kelsi/kelsiandmommy.jpg
A   website/photos/kelsi/halloween.jpg
A   website/photos/kelsi/firstbirthday.jpg
A   website/photos/kelsi/toocool.jpg
A   website/photos/kelsi/batdadandbatkelsi.jpg
A   website/photos/kelsi/longhaireddaddy.jpg
A   website/photos/kelsi/ozzytatoo.jpg
A   website/photos/kelsi/newbaby.jpg
A   website/photos/kelsi/snowwhite.jpg
A   website/photos/kelsi/indeed!.jpg
A   website/photos/kelsi/kelsinow.jpg
A   website/photos/kelsi/computer.jpg
A   website/photos/kelsi/atthepool.jpg
A   website/photos/index.php
A   website/photos/uploaded
A   website/photos/uploaded/portraitweb.jpg
A   website/photos/uploaded/newTV.jpg
A   website/photos/uploaded/ronjonnaedsidcheyney1.jpg
A   website/photos/uploaded/signlicense.jpg
A   website/photos/uploaded/newtatto.jpg
A   website/photos/uploaded/wedding-picture-web.jpg
A   website/photos/uploaded/neutralzone.jpg
A   website/photos/uploaded/house-front.jpg
A   website/photos/uploaded/happy kelsi.jpg
A   website/photos/uploaded/house-left.jpg
A   website/photos/uploaded/biography-cover-jacob.jpg
A   website/photos/uploaded/mvc-007s.jpg
A   website/photos/uploaded/jonna-tattoo.jpg
A   website/photos/uploaded/biography-cover-andrew.jpg
A   website/photos/uploaded/ronring.jpg
A   website/photos/uploaded/house-downstreet.jpg
A   website/photos/uploaded/bridekiss.jpg
A   website/photos/uploaded/conehead kids.jpg
A   website/photos/uploaded/familyatdisney.jpg
A   website/photos/uploaded/biography-cover-ronjonna.jpg
A   website/photos/uploaded/rings.jpg
A   website/photos/uploaded/ronjonna.jpg
A   website/photos/uploaded/livingroom.jpg
A   website/photos/uploaded/andy and dwarf jonna.jpg
A   website/photos/uploaded/vaibox.jpg
A   website/photos/uploaded/andy books.jpg
A   website/photos/uploaded/kids.jpg
A   website/photos/uploaded/ronfirstbirthday.jpg
A   website/photos/uploaded/welcomemat.jpg
A   website/photos/uploaded/house-right.jpg
A   website/photos/uploaded/edcheyney2.jpg
A   qf/source/wildcard.h
A   qf/source/compress.h
A   qf/source/qfw32.c
A   qf/source/qf.c
A   qf/source/qf.h
A   qf/source/crc.h
A   qf/source/qfdos.c
UU  qf/source/QF2.MAK
UU  qf/source/DOSTYPES.H
A   qf/source/qfdos.h
A   qf/source/qfprint.c
UU  qf/source/DOC/QF.DOC
UU  qf/source/QFW32.MAK
A   qf/source/qfllf.8
A   qf/source/wildcard.c
A   qf/source/qfos2.c
A   qf/source/compress.c
UU  qf/source/MAKEIT.CMD
A   qf/source/qfvfy.c
UU  qf/source/QF.MAK
UU  qf/source/QF.STS
D   qf/source/COMPRESS.C
D   qf/source/COMPRESS.H
D   qf/source/CRC.H
D   qf/source/QF.C
D   qf/source/QF.H
D   qf/source/QFDOS.C
D   qf/source/QFDOS.H
D   qf/source/QFLLF.8
D   qf/source/QFOS2.C
D   qf/source/QFPRINT.C
D   qf/source/QFVFY.C
D   qf/source/QFW32.C
D   qf/source/WILDCARD.C
D   qf/source/WILDCARD.H
New merge ticket: 4ddbc19d-f0cf-0310-94ad-fbf59656ec37:/trunk:23

As you can see from the output, we have about 110 changes that have happened to the main SVN repository since we created our local mirror, and all of them are now in our mirrored repository. Luckily during this time, none of the changes we have made to our local branch have conflicted with the changes made to the main repository.

One thing to note as we execute these commands is that the merge ‘from’ and merge ‘to’ repository locations on the command line are actually specified from left to right. The from repository is always the first one specified, and the ‘to’ repository is always specified last.

Now that we have this information, we can merge these changes into our local branch to continue our work. We do this with the same svk smerge command as above, this time without the -C option specified.

svk smerge -l //bieberlabs/trunk //bieberlabs/new-feature-x
Auto-merging (301, 408) /bieberlabs/trunk to
/bieberlabs/new-feature-x (base /bieberlabs/trunk:301).
Waiting for editor...

D   qf/source/WILDCARD.H
New merge ticket: 4ddbc19d-f0cf-0310-94ad-fbf59656ec37:/trunk:23
Committed revision 409.

You will notice that we specified an -l option to the smerge command. This command prepopulates your commit messages with the individual commit messages for the revisions you are merging and allows you to add additional message text to them. I find this very handy for keeping track of the actual changes that have been merged locally. The initial commit message when using this option during our merge looked like this:

 r373@compaq (orig r13):  rbieber | 2004-12-11T13:22:26.271503Z
 Change svn:eol-style to native
 r374@compaq (orig r14):  rbieber | 2004-12-11T13:31:27.979404Z
 Continue updating header with GNU license.
 r375@compaq (orig r15):  rbieber | 2004-12-11T13:36:57.421569Z
 Continue code reformatting
 r376@compaq (orig r16):  rbieber | 2004-12-11T13:39:56.256824Z
 Rename files to lowercase equivelent
 r377@compaq (orig r17):  rbieber | 2004-12-11T14:04:28.117857Z
 Code reformatting
 r379@compaq (orig r18):  rbieber | 2004-12-11T14:24:48.136330Z
 Code reformatting
 r380@compaq (orig r19):  rbieber | 2004-12-11T14:30:28.926752Z
 Code Reformatting
 r381@compaq (orig r20):  rbieber | 2004-12-11T14:55:07.571027Z
 Code Reformatting
 r406@compaq (orig r21):  rbieber | 2004-12-31T13:35:35.719204Z
 Update index.php with new content from production
 r407@compaq (orig r22):  rbieber | 2004-12-31T13:37:40.697066Z
 Back out production changes made in revision 21 and
 update correct index.php
 r408@compaq (orig r23):  rbieber | 2004-12-31T13:44:13.339651Z
 Undelete photos from old web site

Updating your working copy

Now we need to update our working copy from our local branch. We do this by changing to our working copy and executing an svk up command:

rbieber@compaq:~/svk/website> svk up
Syncing //bieberlabs/new-feature-x/website
in /home/rbieber/svk/website to 409.
U   wordpress/index.php
A   photos
A   photos/raytracing
A   photos/raytracing/yinyang2.jpg

Wrap Up

This article has detailed the process of keeping your local mirror up to date with activity going on in your production Subversion repository. Keep in mind that all of the changes have happened on your local machine and that the main repository has not yet been updated. This process can be repeated as often as you like until such time as you are ready to merge your local changes back into the production repository, which will be covered in part 3 in this series. The real beauty of SVK that this article should illustrate is that at no time were we mining for specific revision ranges to merge. Using the smerge command this is all taken care of for us. The software knows about every merge that has happened between your local mirror and your local branches. When we smerge our changes back to the production repository, you will also not be mining for revision numbers. SVK knows what has been merged to your local branch and will automatically skip them on our merge back to the repository.

It is also very important to point out that the only time in which network connectivity was required was during the initial synchronization of the mirror (the execution of the svk sync command). All other actions were performed disconnected from any network.

In part 3, we will cover the final portion of our process, which is taking our local branch and merging our work back to the repository.

Back to Part I | On to part III

4 thoughts on “SVK – Distributed Version Control – Part II

  1. Pingback:

  2. Pingback:

  3. Pingback: Bieber Labs » SVK - Distributed Version Control - Part I

  4. Pingback: » Blog Archive » Using svk to mirror a subversion repository

Comments are closed.