Version Control and Release Management With SVK

SVK is self described as a decentralized version control system built with the robust Subversion filesystem. Possibly more important (although, who doesn't like words like decentralized and robust), are some of the features it supports:

• Repository mirroring
• Disconnected (i.e. network-less) operation
• History-sensitive merging

There are other features it supports, such as patch generation, but those above are the biggies. At this point, those in the open source development community have heard about SVK and I wouldn't claim that it's news, per se. What is interesting is that it works.

For the last year or so, I have been primarily responsible for managing the software release process at my place of employment. This, for me, entails coordination of release cycles (weekly, for us), merging of bug fixes from other developers, and branch management. We used to be a CVS shop, but at some point, I pushed hard to get everyone into Subversion for reasons that should be obvious (if they're not, rest assured they were valid). Our release process was not terribly complicated and was mostly informal, but SVK made it much easier to maintain. Here's it is...

1. Work in dev branch - //rep/branches/dev
2. Developers merge stable code (by their definition) to /rep/trunk
3. Every 7 days, a Release Manager create a stable branch from trunk - svk cp //rep/trunk //rep/branches/stable_yyyymmdd
4. QA team tests stable_yyyymmdd while devs continue to work in //rep/branches/dev and integrate changes into //rep/trunk.
5. QA team gives the stable branch their blessings
6. Release Manager blesses the stable branch into a release by making a copy - svk cp //rep/branches/stable_yyyymmdd //rep/branches/release_yyyymmdd (where the dates are the same)

Points of interest:

• //rep/trunk is where devs can do integration testing
• //rep/branches/stable_yyyymmdd is where QA and executives can preview what is coming
• //rep/branches/release_yyyymmdd is safe to deploy to new machines at any given time
• //rep/branches/release_yyyymmdd is copied from the stable branch so if there are bug fixes, during that testing, the release branch is unchanged and still safe for re-deployment
• devs can cut personal or per-project branches off of //rep/branches/dev should they need to do so, and manage them themselves

What SVK brings to the same, and what many see as one of its killer features, is the smart merging. This means that SVK remembers the source of a branch and the last merge point. This means that if I want to bring all outstanding changes from the dev branch into trunk, I can do:

svk smerge          \
  -m "Merging everything from dev into trunk with original log messages" \
  -l                \
  --to //rep/trunk

The -l option tells SVK to include the original log messages (in addition to the message specified by -m) and the --to <rep> specifies the repository location to merge changes to.

If bug fixes need to be applied, developers merge them from dev to trunk, then request that those changes be merged to whatever the appropriate stable branch is for testing by QA, and eventually the release. As time goes on, we kill off old branches to keep things tidy, but we can always go back and resurrect them should we need to do so.

SVK has significant advantages when traveling or working in an area where the Subversion repository is unavailable, as well. This is probably the other major killer feature. Because SVK mirrors the Subversion repository and keeps it in a local repository, you can continue to commit changes when you don't have access to the core Subversion repository. When you get back to a trust location, you can instruct SVK to synchronize all changes.

While still clunky in a few places, SVK brings some fantastic features to the table with its smart merging and distributed operation. Its patch generation features as well as the ability to synchronize to an external repository make it the perfect tool for customizing or working on open source projects without commit access. At some point, it would be great to see these kinds of features make it back into Subversion, but until then, SVK does what was otherwise a real pain and it does it well. Check it out.

SVK Wiki

Many thanks to Chia-liang Kao and Best Practical for all of their work and support of a great project.