distributed version control

[John W. Eaton]

Now that 3.0 is out, and with more people than ever before
contributing patches to the Octave sources, I think now might be a
good time to consider switching from CVS to a more modern version
control system.

If we look at requirements, I think they are

  * Must have features of a modern VCS:  atomic commits, easily remove
    entire changesets, track filename changes, offline usage, etc.

  * Must allow individual developers to easily create a branch in
    their own private repository, check in new files, delete files,
    rename files, etc., then publish those changes in a way that is 
    simple for others to integrate.

  * Must work on and be relatively easy to install on Windows, OS X,
    and Unixy systems.

  * Must provide a way to publish repository online via a web
    interface with minimal effort (I'd like to retire the chroot cvs
    server that I'm currently running).

  * Acceptable to our community of developers -- how will it change
    the way we work on Octave?  Will it make things better?  For
    example, I find myself spending more and more time just checking
    in changes.  I'd prefer to be able to pull changes from other
    repositories rather than having to run patch all the time.  I'm
    assuming that by pulling in changes from a repository, I would not
    have to remember to "cvs add" new files, or "cvs delete" files
    that have been removed.

I'm sure there are others, so please feel free to add to this list.

Possibilities to consider are mercurial, git, bzr (and possibly
others).  Does anyone on the list have experience with these tools?

We discussed Subversion in the past, but I'm not sure it is
sufficiently better than CVS to bother switching (if I'm wrong about
this, then please tell me whether Subversion can meet all the
requirements listed above).

If we do switch, is it necessary to convert the entire existing CVS
archive to the new VCS?  I mean, at this point, who cares about what
changes were made to files in 1993?  I think the only people who would
care about that would be historians, and we can just keep the old CVS
archive around for that purpose.

Also, if we switch to one and it doesn't work out especially well,
then it seems that we could always switch to another one later, as the
concepts seem to be more or less the same among all the major
distributed VCS tools at the moment, so converting a repository from
say hg to git would probably be easier than the initial conversion
from cvs to hg (or git) (at least if we want to preserve the entire
history of all changes).

Comments or suggestions?

jwe