advertisement

Print

Painless Merging with SVK: An Interview with Chia-liang Kao

by Edd Dumbill
09/20/2005

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?

Chia-liang Kao
svk: Version Control without the Headaches

O'Reilly European Open Source Convention

O'Reilly European Open Source Convention
17-20 October 2005
Amsterdam, The Netherlands

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.

Pages: 1, 2

Next Pagearrow