Re: Offering help with repository conversion

[Mojca M. <moj...@gm...>]

On Thu, Feb 20, 2014 at 9:16 AM, Daniel J Sebald wrote:
> On 02/19/2014 09:43 AM, Eric S. Raymond wrote:
>> I maintain a tool called reposurgeon that edits and convers
>> version-control repositories, and a front end for it called
>> cvs-fast-export that does what its name says.
>>
>> Recently a gnuplot contributor attempting to set up a local git mirror of
>> the gnuplot repository for his own use approached me with a bug report
>> about cvs-fast-export which I was able to resolve. In the process I
>> ran a test conversion of the gnuplot history to git.
>>
>> I am therefore in a position to state that converting your production
>> repository out of CVS into a modern distributed VCS would not be
>> very difficult. If I had an inside collaborator familiar with the
>> project history I think it would be about a week's work.  Most of that
>> effort would be lifting CVS version references in comments into
>> a useful form.
>>
>> I couldn't do it right now, as I'm presently engaged in converting the
>> (much larger and messier) Emacs repository.  But I could help this
>> happen in the relatively near-term future.  As a past (and possibly
>> future) GNUPLOT contributor myself I feel I have some interest in
>> making it happen.
>
> I think a more modern source control program for gnuplot would be good.

Yes. I would really love to see gnuplot switch to a different version
control system. Reasons include ill-behaviour from time to time, CVS
tends to loose data and doesn't know how to handle certain operations
(like moving files around), it's very inconvenient to use and it's
hard to keep track of patches.

>   Some on the list might feel there aren't enough mods to move from CVS,
> but I'm pretty sure others would like a more modern VCS if they were
> used to it.  It aids in development by providing good diff tools,
> exchanging patches, changesets, push/pull, etc.

One huge advantage over the current situation would be that patches
wouldn't get outdated so soon. Whenever someone submits a patch to the
tracker, it either needs to be updated on regular basis if others want
to test it or it will fail to work. I cannot speak about mercurial
because I don't know it (I suspect it's similar), but with git
applying an old patch usually works out-of-the-box. I actually use
git's patching functionality to automatically migrate patches from an
old versions to the new version of code for projects without any
connection to git – I make a new git repository just for the sake of
that "patch upgrade".

> However, I'm partial to
> Mercurial at the moment.  I'm not saying git wouldn't be considered, but
> it would take some convincing that git is preferable to Mercurial.
> (They are both about the same, and both very nice, but I think Mercurial
> is more straightforward.)

This is all just an endless political debate and any argument for git
can probably find a counter-argument for mercurial (and vice-versa).
The tool of choice should be whatever developers of a particular
project prefer, but anything is better than CVS and the sooner it's
left behind, the better.

I would be perfectly happy with subversion as well, but now that other
powerful tools exist, it makes more sense to switch to one of those.

I've chosen git for a few other projects also because it was easy
enough to change history, particularly during the initial
conversion/import from cvs or zips. (That is for example: change
committer's email, fix some inconsistent commit timestamps and
comments, fix some faulty commits and file permissions, merge multiple
repositories into one, merge some commits that shouldn't be separated,
...) But that is not of crucial importance here. (And also because
GitHub is simply great and easy to use.) But I'm not a developer to
have a vote about it.

One pro-git argument would be that the converted repository is
basically ready. (I also made a conversion of the repository a few
years ago on https://github.com/gnuplot/gnuplot, but it's buggy and
doesn't always correspond to what's in CVS. Using cvs-fast-export does
the job a lot better. There were a few minor problems, but those were
fixed.)

But if developers would choose mercurial, that would be fine as well.

> To convert the existing CVS repository I suppose I'd approach it by
> writing in a scripted language with access to unix commands some program
> that successively gets the versions from CVS followed by an appropriate
> commit to the new repository

But why reinventing the wheel instead of, say, patching another tool
that is already specialized in doing exactly that (that is: in case
there are some new problems discovered during conversion)?

Keep in mind that you also need to take care of properly converting
.cvignore files, take care of a number of branches, tags etc.

Nobody says it isn't doable, but why spending days on writing yet
another buggy converter that would be abandoned after doing the job
and would do a suboptimal job anyway?

> with the extracted comment used during the
> commit steps.  One would have to check status for new or deleted files,
> but I think it would be doable.  Just let the computer run overnight.

With existing tools the job can be done in about an hour
(cvs-fast-export generates a 3 GB plain text file for import into
another version control system).

Mojca