Re: distributed version control

[Thomas Weber]

Am Mittwoch, den 16.01.2008, 16:23 -0500 schrieb 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.

+1.


> 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.

I'd say that there should be more than one way to forward patches (e.g.,
people without a webspace should be able to send patches by mail simply)

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

>   * 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.

It should be possible to have a trust model: e.g., if someone suggests a
patch that's only for Windows, it should be possible to point him to
Michael. If Michael accepts the patch in his repo, you can simply pull
from there. This is definitely possible with Git (Linus pulls only from
a few people).

Also, an easy interaction with a future bugtracker might be nice.

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

I currently use Mercurial, but have also use Git occasionally. One thing
about Git: it's fast, even on large files (> 100 MB). However, I find
its interface with the staging area ("index") unintuitive. Other people
might disagree. Git is written in pure C, this might be a problem on
Windows. But if things grow large, Git is definitely the tool. 

Mercurial is mostly written in Python, only a few speed-important things
are written in C. This made porting easier.

Bzr: the slowest of the three, but arguably the one with the best UI.
Haven't used it myself, though.

> 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).

No. We use Subversion for the Debian added content to the Octave
packages, and it doesn't fullfil most of the stated requirements.
There's SVK (some sort of addon), but I'd say it's not worth bothering.

> 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.

The conversion tools from CVS to other system are quite mature. It might
be possible to convert the entire history! These repositories don't
become that large:
"Note that e.g. CVS-imported glibc repository with ~15 years worth of
history is just 100M."
http://repo.or.cz/about.html

> 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).

Yes. The problem with CVS is its non-atomic commit handling. If you
commit changes to three files at once, CVS creates three patches,
instead of one.

        Thomas