Today at EuroOSCON, I attended a introductory talk on svn by Chia-liang Kao. I was hopeful that svk might address some of the issues that I thought would prevent us from adopting Subversion for OpenSolaris. In particular, Subversion requires a centralized repository whereas svk, which is built on top of Subversion, provides the distributed revision control system that we’d need. After the talk, my overall impression was that svk seemed to lack a certain polish, but after struggling to phrase that in less subjective terms, I’m coming around a bit.
I got a little nervous when the first example of svk’s use was for keeping the contents of /etc under revision control. The big problem that svk solved was having random directories (.svc, SCCS, whatever) in, for example, /etc/skel. Talk about trivia (almost as relevant as a demo implementing a weblog in Ruby on Rails). I guess it’s nice that svk solves a problem for that particularly esoteric scenario, but wasn’t there some mention that this might be used to, you know, hold onto source code? Was that actually the design center for svk?
Fortunately we did get to the details of using svk for a source code repository. I think this is just my bias coming from teamware, but some of the mechanisms seem a bit strange. In particular, you do svk mirror to make one kind of copy of the main repository (the kind that’s a “local repository”), and svk checkout to make a different kind of copy (the kind that’s the “working area”). In other words, you have a tree structure, but the branches and leaves are different entities entirely and editing can only be done on the leaves. I guess that’s not such a huge pain, but I think this reflects the origins: taking a local revision control system and making it distributed. Consequentially, there’s a bunch of stuff left over from Subversion (like branches) that seem rather redundant in a distributed revision control system (don’t take branch, make another local repository, right?); it’s not that these actually hurt anything, it just means that there’s a bunch of complexity for what’s essentially ancillary functionality.
Another not-a-big-deal-that-rubs-me-the-wrong-way is that svk is a pile of perl modules (of course, there’s probably a specific perlism for that; “epocalyptus” or something I’m sure). I suppose we’ll only have to wrestle that bear to the ground once, and stuff it in a tar ball (yes, Allan, or a package). To assuage my nervousness, I’d at least like to be confident that we could maintain this ourselves, but I don’t think we have the collective perl expertise (except for the aforementioned Alan) to be able to fix a bug or add a feature we desperately need.
I want this thing to work, because svk seems to be the best option currently available, but I admit that I was a bit disappointed. If we were going to use this for OpenSolaris, we’d certainly need to distribute it in a self-contained form, and really take it through the paces to make sure it could do all the things we need in the strangest edge cases. As I mentioned, we currently use teamware which is an old Sun product that’s been in constant use despite being end-of-lifed several years ago. While I like it’s overall design, there’s a bunch of work that would need to happen for it to be suitable for OpenSolaris. In particular, it currently requires a shared NFS filesystem, and we require you to be on the host machine when committing a change. Adding networked access capabilities to it would probably be a nightmare. It also relies on SCCS (an ancient version control system) for managing individual files; not a problem per se, but a little crufty. Teamware is great and has withstood the test of time, but svk is probably closer to satisfying our requirements.
Update: But there are quite a few other options I hadn’t looked into. Svk no longer looks like a front runner. If there are other systems you think are worth considering, let me know.
I’ll play with svk some more and try to psych myself up for this brave new world. I’d appreciate any testimonials or feedback, and, of course, please correct all the factual errors I’m sure I committed.
Technorati tags: EuroOSCON OpenSolaris svk
5 Responses
SVK isn’t the only option available, of course. There are lots of other distributed revision control systems (perhaps a bit too many even) which are already pretty mature.
<dl>
<dt>Mercurial</dt>
<dd>Relatively new, a little bit rough around the edges still, but already used by <a
href=”http://xenbits.xensource.com/xen-unstable.hg”>Xen as a replacement for BitKeeper.</dd>
<dt>Monotone</dt>
<dd>More mature than Mercurial, uses SHA1 to <a
href=’http://www.venge.net/monotone/docs/Historical-records.html#Historical-records’>identify changesets.</dd>
<dt>Bazaar</dt>
<dd>An implementation of the <a
href=”http://www.gnu.org/software/gnu-arch/”>Arch protocol. Focuses on bringing more usability to Arch.</dd>
</dl>
No doubt you’ve already looked at the other options available, and I shouldn’t turn this into a listing of all available rcs (there are <a
href=’http://zooko.com/revision_control_quick_ref.html’>much <a
href=’http://www.livejournal.com/users/bramcohen/17319.html’>better <a
href=’http://www.dwheeler.com/essays/scm.html’>resources available for that), so I’ll just stop here. 🙂
I’m not sure you’ve completely understood how SVK works. I’ve been using it for a couple of weeks now, and I think your workflow would broadly be as follows.
You would have one or more Subversion repositories. These would be hosted somewhere central, and are your master copies of everything.
Your developers use ‘svk mirror’ and ‘svk sync’ to maintain their local mirrors of these repositories (or some subset thereof, depending on what they’re working on).
By convention, these mirrors end up in some directory under ‘//mirror’.
Then the developers make a copy of the files under //mirror to somewhere else (by convention, starting with //local). Suppose, for the sake of argument, that you had the kernel in its own Subversion repo. A developer working on the kernel might start with:
svk mirror //mirrors/kernel URL-for-kernel-repo
svk sync //mirrors/kernel
svk copy //mirrors/kernel //local/kernel
The first command creates the mirror mapping. The second command does the actual mirroring, and the third command makes the copy.
Now your developers can check out //local/kernel in to their local filesystem (“svk co //local/kernel”) and start editing files, and so on.
So far, there’s no real difference to what you can do with Subversion.
The clever bit is that your developers can now commit to //local/kernel without needing network connectivity to the master repository.
Subversion doesn’t let you do that — in order to commit you need to be able to reach the main repo. With svk you commit to your locally mirrored repo.
When your developer has network connectivity again they can “svk push” to put their changes back to the master repository
Branches and the like are still useful in this situation. Suppose the kernel source is organised following Subversion guidelines, so you have /kernel/trunk for the mainline of development and/or stable code, and /kernel/branches/name-of-branch for development that’s in progress but that is not ready to hit the trunk yet.
Suppose your developer is working on some spiffy new feature for the kernel that’s going to take some time to develop. Instead of working on the trunk they’d likely want to work on a branch instead. To do that, they’d do this (after running the three commands previously).
svk copy //local/kernel/trunk //local/kernel/branches/spiffy
svk checkout //local/kernel/branches/spiffy
cd spiffy
… edit away, making as many commits as they like …
As before, when your developer has network connectivity back to the main repo they can “svk push”. This will create the branch back in the master repo, and propogate all the developers commits (either one by one, or as one large commit) back to the repository.
One of the really useful features about svk is that it remembers what was propogated back and forth when you do “svk push”, so the command can be run multiple times and it will do the right thing.
Drop me a line if you’d like me to talk through this some more.
don’t panic. i’ve already worked through packaging svk for solaris — see above URL
SVK is certainly a candidate for use with OpenSolaris but, as Bart’s list suggests, it is neither the only candidate or the leading candidate. (There is no leading candidate.)
Evaluation of the distributed SCM choice is an upcoming phase, after the current items blocking development of the governance documents and project source code release are addressed. Investment in any particular choice may end up having limited returns…
— Stephen
A distributed SCM with very solid foundation (theory of patches) is DARCS (http://abridgegame.org/darcs). It is definitely worth having a thorough look into it.