Reality never quite lives up to the marketing. While I think svk is a great product and am seriously considering switching several Debian packages to using it, there are some important tradeoffs to consider. The first thing that struck me while looking at svk is that it is somewhere between alpha and beta quality software. The documentation consists of a wiki and some online help. The command line interface is clunky when compared to the svn command line. for example "svk help foo" works but "svk foo --help" does not. Similarly you cannot include option values just after POSIX style options; this is annoying for "-r". When things die you tend to get internal errors and tracebacks that often don't seem to relate to what you were doing. IN other words, the error handling tends to present implementation errors even when interface errors would be appropriate. I've managed to get svk confused about working copy state and end up needing to check out a new working copy. I don't have a reliable way to reproduce this.
Normally, I've not been interested in anything less than production quality SCM software. However svk is built on top of the Subversion filesystem. I have high confidence that once my changes are committed, they will stay committed and that I will not be subject to repository corruption. IN terms of consequences of bugs, it seems more like using a beta quality UI on top of a revision management system. However, since svk does manage the working copy itself, you probably want to be more careful with your working copies than you would be with cvs or svn. Also, if things go sufficiently wrong with a merge, you may potentially get metadata claiming that a merge has happened when it has in fact not happened.
The second thing I noticed is that the divergence between svk and svn is more than I expected. Svk does not use the svn_ra layer to access its repository; instead it uses svn_fs. This means that you need to have a local repository on the same computer as you are running svk. You can use the mirror and sync operations to mirror and later change a remote repository, but you cannot directly work on a remote repository. This seems silly for computers that actually are on the net all the time, but disk is cheap and I suspect there is some good reason for this decision. Svk has a completely different working file format than svn. Svk working directories split their state between ~/.svk/config and the files in the working copy. The good news is that svk working copies count as exports and so there is no export operation. The bad news is that working copies are specific to a single user home directory; this can interact badly with network filesystems. Of course since Subversion repositories currently don't work well with network filesystems and your working copy is bound to a single repository, this is not much a new limitation.
The next big question raised in the discussion was how well does mixing svn and svk on the same repository work. There are two things you could mean by this. How well does it work to have some users directly manipulate a remote svn repository and other users use svk mirror and svk sync on the same repository? This seems to work at least as well as using svn all the time. Clearly the users who don't use svk don't get the benefits of svk. Also, if svn users perform merges, you won't get all the metadata you get with svk merges. However there is another repository for which you could mix svn and svk: the local repository that svk operations typically work on. This is somewhat more dangerous and probably is worth avoiding without a reason to use both tools. The big problem seems to be that you will destroy your ability to sync a mirror if you manipulate the mirrored copy with svn directly. Manipulating copies (branches) of the mirror is fine. Again, merging with svn loses metadata.
I then played around with things to see how well they work. The answer seems to be that they do in fact actually work as advertized. You get offline development and you get the ability to do smart merges. This seems very nice for packaging efforts or if you actually care about offline development. Performance seems good although I didn't test anything that would have stressed the system. Here's my list of things that didn't really work:
- Mirroring a cvs repository into svk is a new feature and is not quite ready for prime time yet. Here are the problems I see:
- Vcp, one of the dependencies, does not pass its self tests.
- It deals poorly with errors; failed to work on two of the three repositories I tried.
- Tags are not currently supported although branches are.
- Handling of cvs vendor branches interacts badly with smart merges. I'm not sure how this should/could be fixed.
- Rename/move is not useful yet. You can only rename files in the repository; you cannot rename things in the working copy and commit later. Also, the merge system will not cross renames when merging changes from a branch without the rename into a branch that has the rename.
- The cmerge command seems to have some atomicity problems where it does not either cleanly succeed or fail. It left what I hope are temporary branches around in the repository and committed some property changes even though the merge failed.
- The source of a copy must be a repository reference not a working copy reference.
All in all, I am fairly happy with svk. I want to move the Debian PAM package onto a repository on svn.debian.org as a test of svk. I need to decide repository layout issues and figure out how I'd deal with merging upstream changes given that upstream still uses CVS.