SVK 1.00 and WordPress 1.5.1 releases.

Chia-liang Kao, author of the SVK source control tool, announced the release of SVK 1.0 final today.

And if that wasn’t enough for you, the WordPress folks have announced the release of WordPress 1.5.1. Download it now. Information on what has changed is available in the ChangeLog on the codex.

Update: 5/10/2005
A quick check of CPAN this morning finds SVK 1.0 out on the mirrors. Go ahead and install it with the following (as root):

perl -MCPAN -e 'install SVK'

SVK 1.0 Beta 2 released.

Yesterday, the release of SVK 1.0 Beta 2 was announced .

The announcements list the following changes since Beta 1:

  • Fix keyword translation for undesired characters. [matthewd]
  • Fix svk switch from a removed branch.
  • Don’t trust LML would return a valid encoding that Encode knows. [Eric Gillespie ]
  • Recognize merge-conflict error, so no stacktrace for it.
  • svk info now skips files not under version control. [#8220] [gugod]
  • Fix locked mirror messages.
  • Various pool usage fixes.

The software can be downloaded from the SVK download area.

Explaining the SVK Workflow

As I’m beginning to talk to people about the SVK version control tool more, I’m noticing that the concept of mirroring isn’t as obvious to some people as it was to me when I started messing around with it (or maybe I just choose not to remember how unobvious it was), so I thought I would take some time to try to explain some of the concepts at an extremely high (and hopefully easier to understand) level.

Sometimes the best way to explain a concept is with a picture, so I threw together this small data flow diagram that shows the flow of data through the SVK system and what commands cause this data transfer to happen.

SVK WorkFlow

The basic high level workflow of an SVK session looks like this:

  1. Create A Mirror
    You mirror the repository using the svk mirror command. For me, I find it easiest to create my mirrors at the topmost level (for example, a mirror of the bieberlabs trunk might be at //bieberlabs/trunk).
  2. Synchronize Your Mirror
    This brings down the revisions that you do not have yet in your main (and remote) repository to your newly established mirrored path.
  3. Create a Local Branch To Do Your Work
    Many times I see that people default to checking out from the actual mirror (in the above example, //bieberlabs/trunk). This will work, but you lose the whole beneifit of SVK. If you check out of a mirror, every commit you make will be synchronized back to the main repository. This is not desired behavior most of the time. So, create a local branch first. I like to create a top level directory in the repository called //local that I put my local branches in, just so I know where to find them.
  4. Periodically synchronize your mirror and merge those changes into your local branch
    This is where all of the power is. You now have a local branch that you can keep completely up to date with the repository that others are doing work in. Using the svk smerge command, you can merge changes from //bieberlabs//trunk to //local/mychange as you synchronize your mirror. This allows you to always be working on the current code. You can commit your work and not effect anyone else working in the repository until you are ready to merge into the mirror.
  5. Once you have merged changes to your local branch, update your workarea
    A common misunderstanding when you smerge into your local branch is that the changes appear magically in your workarea. This is not the case. Remember, when you are smerging you are working in the repository. You still have to update your workarea (and possibly resolve conflicts) from the repository in order to reflect your changes.
  6. Merge your branch back into the mirror
    Once you have finished your change, tested and committed (probably multiple times), you can now smerge your branch back into the mirror. When you perform this merge, the changes will be moved to the source repository and subsequently synced to your mirror (the line in the diagram is red to signify this). Once this happens, all of your changes are visible to everyone else, in one commit.

Here’s the nice thing about working like this. When merging back and forth, you are not searching for ranges of revision numbers to merge. SVK remembers each merge done, so you can use your local branch forever, because you can constantly keep it up to date. This gets rid of the “make a branch, change the branch, merge the branch , delete the branch” cycle and allows you to have one place to work all of the time.

I hope that this really high level view gives a better understanding of the workflow surrounding using SVK and illustrates very simply the advantages of the tool.

For a step by step walk through the tool, you can go through the SVK tutorials.

SVK 0.30 Install for Windows Available

An installer for SVK 0.30 for Windows is available here. This is not a standalone .EXE file, but an installer for the SVK tool.

Some caveats from looking at it briefly this morning:

  • Make sure you have Subversion installed. I thought I had installed it already on my Windows XP machine – but I was wrong.
  • I was unable to authenticate with my SSL WebDAV server through SVK. I had to execute an svn ls https://blah.blah.blah in order to authenticate properly. Once I did this, I was able to create a mirror and sync to it.

I’m not sure if this is the “official” version of the Windows install, but it is one that is available for those who want to start running 0.30.

SVK – Distributed Version Control – Part III


Last week we explored using a local branch and keeping it in sync with the main repository. We also explored the incremental synchronization of local mirrors on our machine. This week we will be merging our changes back into the main repository and wrapping up our discussion of SVK for now.


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.

Merging From Your Local Branch To The Mirror

At the end of our last article, we had finished the work that we wanted to do and now we would like to merge our changes into the main repository so that others can access our changes. The assumption is that we have performed all of the due dillegence that software developers perform when they finalize a change and are ready to have those changes activated in the main repository, including keeping our local branch up to date with the main repository using the repository synchronization techniques outlined in previous articles and merging them into our local branch to keep our workarea current.

The time has finally come where everyone who uses the main repository gets to see the changes we have been working on.

When merging to a mirrored tree in SVK, we use the smerge command just like we would in our previous work, only this time the source and destination are switched. We are now merging to the mirror, however the process looks the same. The really cool thing about SVK however, is that when you perform a merge to a mirrored path, you not only update your mirror, but the repository that the mirror points to is also updated simultaneously.

So lets do it. Before actually performing the merge, connect to the network and sync your local repository.

svk sync //bieberlabs/trunk

Now that we are synced up, we will perform an svk smerge -C command to make sure we have no conflicts.

rbieber:/~>svk smerge -C //bieberlabs/new-feature-x _
Auto-merging (0, 409) /bieberlabs/new-feature-x _
to /bieberlabs/trunk (base /bieberlabs/trunk:408).
Checking locally against mirror source _
U website/index.php
D website/familypictures
New merge ticket: fd3a5cf1-f4e9-0310-b907-bd1e11f8034a: _

Some things to notice. Previously we saw quite a few changes coming from the mirrored repository to our local branch, including the re-adding of a photos directory with 68 pictures in the main repository. None of these changes are being merged back to the mirror. SVK is keeping track of the merges we have made from the main repository to our local branch and filtering them out (or skipping them) for us.

It winds up that with all the activity between the main repository and the local branch, the final result is that the only changes made by us in this whole process were the deletion of a directory, and modifications to our index.php file — and SVK knows that. We didn’t have to spend a lot of our valueable time towards an impossible schedule to figure it out!

Now that we know there are no conflicts (it’s nice to live in a perfect world!) we can actually perform a real merge to the mirror. We do this by substituting (in this case) the -C option with the -l option to get an initial log message that reflects each of our individual commits so we know what changes have been made through the time we have been developing on our local branch.

rbieber:/~>svk smerge -l //bieberlabs/new-feature-x //bieberlabs/trunk
Auto-merging (0, 409) /bieberlabs/new-feature-x to _
/bieberlabs/trunk (base /bieberlabs/trunk:408).
Waiting for editor...
Merging back to mirror source _
U website/index.php
D website/familypictures
New merge ticket: fd3a5cf1-f4e9-0310-b907-bd1e11f8034a: _
Merge back committed as revision 24.
Retrieving log information from 24 to 24
Committed revision 420 from revision 24.

As you can see from the above messaging, a few things have happened during the actual merge:

  1. We were prompted for a log message. Even though this is prepopulated, you have to add something to it to let the tool know you want to continue with the merge, just like SVN and CVS.
  2. Our changes were merge to the mirrored path as we specified.
  3. Our changes were then merged from the mirrored repository to the main repository — automatically exposing them in the main repository for other developers to subsequently pull down.
  4. Our mirror was automatically resynced to be current.

Just to verify that our changes made it to the repository, we can go to our local installation of ViewCVS to verify the commit:

ViewCVS Screenshot

In Conclusion

In the last three articles, we have the basic areas of distributed, activity based development necessary to get someone new to SVK productive. I hope that as we have walked through the use of this tool, I have illustrated the huge gains you can receive from beginning to use it.

There are obvious areas in which I have neglected to cover from a conceptual level like conflict resolution, however this process under SVN is covered quite extensively in the Resolving Conflicts chapter of the SVN book written by the Subversion developers. There are also other commands and types of merges that SVK can perform that I will leave to the reader to explore.

SVK is a very powerful tool. The main disadvantage of it is that is written in PERL, and therefore can be difficult to install, and slow to start up. However, these disadvantages are far outweighed by the advantages that the tool brings to the table.

The ability to work while disconnected from a central repository and the automatic merge tracking features of SVK are of incredible value to anyone wanting to give flexibility and true distributed capabilities to their development staff. I highly recommend that you take the time to explore this tool and explore for yourself the new capabilities and flexibility, not to mention just plain time savings SVK brings to the table.

Back to part II | Start Over at Part I