Re: distributed version control

[John W. Eaton]

On 17-Jan-2008, tarmigan wrote:

| I think you should be able to do it with
| 
| cd octave_git_eval
| export CVS_RSH=ssh
| git-cvsimport -d :ext:address@hidden:/cvs -k -u -v -m -p -Z,9 octave

OK, thanks.  I checked and I don't think we have any keywords in the
sources ($Author$, $Revision$, etc.), there are no underscores in any
of the tag or branch names, and the commit messages are almost all
empty.  So it doesn't hurt that you used the -k, -u, and -m options,
but I don't think that they are doing much for the Octave sources.  I
worked on a local repository where compression probably doesn't matter
much, but the -Z 9 option for cvsps might have helped your remote
access.

In any case, I tried this and generated an archive in a reasonable
amount of time.  Then I converted it to an hg archive, and that didn't
take much time either.  The svn to hg conversion was still going after
more than thirty hours and had generated 2.5GB of files, so I killed
it.

After looking at the generated archive, I'm not sure that it matters
all that much that we keep anything except the trunk since 3.0, and
the 3.0 branch.  Other branches along the way were typically created
because I wanted to work on a fairly large project without disturbing
the the trunk (something I think would be done differently with git or
hg), but for which the branch was not really necessary as a history of
anything other than a safety net and a place to do some scribbling.
I'm not sure these things really belong in the archive.  And, if you
really want to see that history, the old CVS archive can still be
available in some form.

One thing that will clearly have to change is that changesets need
a meaningful label.  I'm accustomed to doing

  cvs commit -m ""

because the commit message was mostly worthless anyway.  Now that a
changeset is useful as a collection, I think we will need to attach
some names here.  However, I'm not sure I care to have ChangeLog info
in the commit message.  A simpler title like "residue bug fix" would
probably suffice, perhaps with a pointer to a mailing list thread or a
bug report number (if/when we have a real bug report tracker).

So I'd say we go ahead and choose between git and mercurial, import
just the trunk and 3.0 branch since the 3.0 release (I'm assuming this
is not too hard to do) and try it for a while.  I'd say I'm sort of
leaning toward mercurial, but I don't have a strong opinion about it,
and no real experience using either one.  I think the important
question is which one will be easiest for the majority of the most
active developers to install and use.

jwe