Re: [Qemu-devel] What does code_copy_enabled do?

[Ian Jackson]

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.