It seems to me that there are two questions here: * Should the CVS for the upstream repository be replaced with something else ? * In the meantime, or if upstream decide not to, what is the best way for non-upstream contributors to collaborate with each other ?
The answer to the first question is unambiguously `yes', I think. There are approximately five serious contenders for the replacement: svn, darcs, hg, git, bzr. Switching now to any of the drcs's would be unlikely to be regretted in the medium to long term. I haven't used darcs, but I'm in a perhaps slightly unusual position of having used all of hg, git, bzr and cvs. (I've touched svn too but haven't done anything at all complicated with it, like branching.) I think that for cvs refugees, the right answer is bzr. [1][2] bzr is strictly better than cvs in almost every respect. In particular, refugees from cvs and svn will find it easy to get to grips with. To a large extent you can just say `bzr whatever' instead of `cvs whatever', confident that it will do the right thing - and guessing is safe because even if that was the wrong rune it generally won't do something crazy and make a hideous mess. The areas where bzr is comparatively weak (performance, advanced forms of merging, lightweight branching, etc.) are already worse in cvs. On the other hand, git's and hg's weaknesses are clear regressions from cvs. git's user interface is frankly appalling. It's very functional and some day I hope to see a wrapper which makes git look more like the way everyone expects an rcs to work, and avoids blowing off one's leg. In the meantime I do use it myself but I'm wary of pushing it. hg is much better. OTOH it does have one severe problem: it expects you to check in before merging, which is the opposite of what cvs users expect. A cvs refugee, or anyone working on a project whose leaders don't like merge changesets (yes, they exist) will notice new changes upstream and decide to merge them into their current tree with `hg pull -u', which is the equivalent of `cvs update'. However, that rune's handling of merge conflicts is catastrophically bad and likely to lead to the working tree being effectively destroyed, possibly losing a great deal of work. As I've said, I think there is no point switching from cvs to svn. It's true that cvs's lack of the concept of a changeset is a serious problem and makes mirroring a cvs repository something of a challenge. However, there is already software to reconstruct changesets from cvs logs, and provided the cvs users use cvs in a sane and predictable way (which current qemu upstream do) those conversion tools do work. svn's support for branches is even worse than that of cvs's; this is frankly astonishing given how painful branches are to work with in cvs and how long this has been known to be a serious problem. But really my point is that change is painful so if we're going to try to switch to a new revision control system, with all of the learning, messing about with new software, cursing, and so on, we should try to get as much benefit as we can for our effort. Anyone who switches to svn now will, I think, regret it in another few years. The pressure to switch to a drcs will not go away. On to the second question: What should those of us who want to collaborate using a drcs (so that we can share our work-in-progress patches and generally avoid blocking on upstream) do in the meantime ? Having a private mirror of a drcs is all well and good but no-one can pull from anyone else because each cvs/svn->drcs conversion yields an incompatible history. At the very least we need one drcs branch containing only changes from the upstream cvs. It has to be incrementally updated, automatically and frequently, and generally be well maintained. Most of the potential users seem to be fans of git which is fine by me. If there is someone who knows git better than me and would like to provide a properly supported regularly updated git mirror of the upstream cvs then I would be happy to use and pull from it. Otherwise I would be quite happy to maintain such a thing on www.xen.org (the website for the Open Source Xen). Ian. (I hope the Reply-To munging hasn't caused anyone to be dropped from the CC; I've done a quick check but please forgive me if I missed one.) [1] Full disclosure: Not everyone may be aware that I spent a couple of years working for Canonical as an Ubuntu developer; I left in November. I didn't work on bzr. IMO my recommendation of bzr is best regarded as despite my relationship with Canonical, rather than because of it. [2] Some people think that bzr has some kind of dependency on Launchpad. This is not the case. If it did I wouldn't be recommending it.