Author's note: If you're always on the lookout for better ways to manage your source code, chances are you've heard of the Subversion-based SVK system. At O'Reilly's EuroOSCON (October 17-20) SVK's creator, Chia-liang Kao, will explain how SVK has removed the headaches from source control.
So what's so special about SVK? O'Reilly Network spoke to Chia-liang Kao to get a sneak preview of his upcoming presentation.
Edd Dumbill: You're talking about SVK at EuroOSCON. Firstly, what is SVK and how long has it been around?
Chia-liang Kao: SVK is a distributed version control system I started developing during a year's sabbatical I took back in 2003. I released version 1.0 in May 2005.
ED: What are SVK's major innovations?
CLK: SVK allows distributed development using existing infrastructure, which means you don't need to deploy a new system for your whole organization. SVK works best with Subversion, but you can also seamlessly branch from CVS, Perforce, or even git repositories. SVK lets you commit directly back to Subversion repositories and "commit as a patch" to other systems or to Subversion repositories you don't have commit access to. Such patches can then be applied by the maintainer, using either a regular patch tool, or SVK, which also will help filling the commit log.
ED: Why is SVK's "painless merging" important? Does it matter outside of open source projects?
CLK: Painless merging means you can merge changes from one branch to another with a single command--SVK will "Do What You Mean." It makes things easier for contributors to open source projects to maintain their patches as a local branch and accept changes from upstream, rather than being treated like second-class citizens who have to deal with patch hell just because they can't commit. You can do this with many other version control systems using "vendor branches," but mostly they require too much work to maintain a short-lived branch just for a patch or two that haven't yet been reviewed and committed.
Open source projects sometimes fork because it's too hard to integrate branches that have diverged too much. Painless merge makes it much easier to branch instead of fork.
Outside open source projects, it's also very common to maintain vendor branches with local modifications. SVK can import new versions of third-party software with just a single "pull" command.
In many organizations, it's also common to do development on a separate branch, and then merge tested changes to the stable branch. SVK can make this a lot easier but yet is flexible enough for more complicated scenarios.
ED: Can you explain how working offline with SVK works?
In Subversion, branches are just copies of a tree. For example if you have /project/trunk copied to /project/local, the latter is a branch of the former.
SVK marks some parts of the tree as a mirror of a remote repository, and all the commits that write to that directory will be mapped as committing to the original remote repository. So in the example, suppose /project/trunk is mirrored from your Subversion server at http://project.org/svn/trunk. When you do a push for /project/local, it then merges to /project/trunk, and thus commits to the remote repository.
ED: Is it possible to use SVK as a branching tool, but still work with people who are based on CVS or Subversion?
CLK: You can use SVK as a branch and merge tool while others use Subversion. But to work with people using CVS, SVK only makes it easier for you to maintain your own branched development and submit patches. It would probably be a week's work to let you commit back to a CVS server, but that's not a feature I, or many of our users, have needed yet.
ED: At the U.S. OSCON, Leon Brocard demonstrated SVL. Can you explain what SVL is, and which problems it solves?
CLK: SVL is a very thin layer on top of SVK, along with Bonjour (ZeroConf) and OpenDHT. It allows peer-to-peer repository communication without a centralized server. For instance, in a room full of hackers, when people come up with a cool idea and want to start hacking right away, they shouldn't need to set up a centralized repository somewhere and make everyone use it. With SVL, repositories are advertised, people can just branch from each other, and then pull from each other.
ED: Do you have ambitions for SVK beyond scratching your own itches? Is there any interest from vendors in supporting it, or any other major installations beside your own?
CLK: Since SVK talks to other version control systems, there are many open source projects with their committers or contributors using SVK against their Subversion repositories, or even CVS servers. KDE, WINE, Samba, and those listed on svk.elixus.org are among them.
My employer, Fotango, uses SVK to maintain vendor import and branches. Most of my coworkers have moved from Subversion to SVK for daily use, mainly because SVK is a lot better at handling trees at the kinds of sizes we have.
Best Practical, maker of the popular request tracking system, "RT," are happy users of SVK. In fact, SVK enables them to effectively maintain many parallel branches, which they tell me used to be a bit of a nightmare for such a small shop.
I am also told that at Apple Computer, there is an entire team using SVK exclusively.
ED: The work being done by Canonical with Bazaar follows a similar sort of path to SVK: decentralization, easy merging. Where do you see SVK in comparison to this and other arch-based systems?
CLK: One major difference is that we are using the Subversion file system as a storage format and can talk to Subversion repositories natively.
Subversion is probably the most popular centralized version control system besides CVS. This means we benefit from the stability and the improvement from the Subversion team and contributors.
SVK has been assimilating many nice features we've found in other systems. For example, we're about ready to roll out a new interactive commit feature, based on the one found in Darcs. It makes it easy to commit only a subset of your outstanding changes by prompting you for each "chunk" of change in each file.
In the past, we've adapted smart merge functionality based on the original design in arch, Perforce-style depot paths and interactive conflict resolution, and we're working on patch-algebra from Darcs. We're also watching Bram Cohen's Codeville Precise Merge as a possible even-smarter-than-smart merge.
We're always on the lookout for new technologies to make SVK an even better tool for our users.
Edd Dumbill is co-chair of the O'Reilly Open Source Convention. He is also chair of the XTech web technology conference. Edd conceived and developed Expectnation, a hosted service for organizing and producing conferences. Edd has also been Managing Editor for XML.com, a Debian developer, and GNOME contributor. He writes a blog called Behind the Times.
Return to the O'Reilly Network
Copyright © 2009 O'Reilly Media, Inc.