Re: distributed version control

[tarmigan]

On Jan 16, 2008 1:23 PM, John W. Eaton <address@hidden> wrote:
> 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.

I'm very happy that you are suggesting this.  I was considering
suggesting something like this, but am obviously not one of the
maintainers, so it would have been a bit presumptuous.

IMHO, git and hg are the best candidates.  I have been playing with
git for around a year now, and think it would work well.   Note that I
am not an expert on git, just a happy user.  See more below.

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

Both hg and git have these.

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

Both hg and git would work.

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

Hg probably has slightly better windows support than git.  Like
octave, git likes a unixy environment to build.  Git on windows is
improving fast, and the binary works well for me at work.  I have
encountered fewer bugs in the windows version of git than in the
windows version of octave if that is any indication.

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

Git can read over http, ssh, git:// or a (networked) file system.  You
can push changes over ssh.  You can also browse changes online through
something like http://repo.or.cz/w/git.git

The typical workflow for something like octave might look something like this:
- jwe works on his repository.  When we is ready, he pushes over ssh
to octave.org.
- other people fetch jwe's latest changes via git:// or http://
- they then do work and email patches, or publish to their own
repositories on octave.org (e.g. David Bateman might have his own ssh
account and git repository on octave.org)
- jwe can integrate the emailed patches as he sees fit, or can merge
in branches from other repositories when they are ready.

I'm not as familiar with hg, but I think the workflow would be similar.

>   * 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 believe it would be an improvement for several reasons.

First git has an included cvsserver, so it can emulate cvs for those
who do not want to change to git yet.

Second, you can pull in a whole bunch of changes all at once.  For
example, the dbateman repository could have all of the patches that
got emailed to the list, which he applies to his repository from
email.  Then he could say to JWE, "I think these changes look good,
please do a git pull git://git.octave.org/dbateman.git" and JWE's tree
would get all of those changes.

Third, it is much easier to maintain seperate branches out of
mainline.  For example, the "object" branch could have simmered for
longer out of mainline but still been kept up to date.  This has
advantages because an intrusive series of changes can be kept out of
mainline (but up to date) until they have been vetted and tested, with
much less effort than with cvs.

Finally, you can create changes as a series of small changes.  This
allows you to later go back and "bisect" a bug down to a single, small
commit more easily, at which point the bug will hopefully be obvious.

One minor disadvantage of pulling directly from people's tree's
instead of emailing patches, is that there may be less visibility and
review.  This can be mitigated by having initial versions of all
patches sent to the list, and by only merging from people whose code
and judgment you trust.

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

I have played with git, and can answer some (easy) questions about it.

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

We use svn at work, and I would recommend git for octave.

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

It is not necessary, but it can be nice.  I have been following the
octave cvs with git (including a full history).  I don't know the size
of the repository off the top of my head, but I will check tonight.
Another option is to start with a clean slate and have people who want
that full history use a "graft" in git, which lets you pretend that
the historical tree is joined with the current one.

As a side note, I have also been tracking octave-forge with git, and
it works well.  So even if octave-forge stays with svn, git would be
able to interact with it.  Personally, I would love to see
octave-forge become just a separate branch of the main octave
repository.

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

My conversion of the cvs repository has not been super clean, and it
might be worth spending some time making sure the history gets
imported nicely.

> Comments or suggestions?

Sounds great, and my vote would be for git, though other people seem
happy with hg too.

Thanks,
Tarmigan