Re: cvs import

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Sep 14, 2006, 05:36 UTC
Message-ID: <4508EA78.5030001@alum.mit.edu>
In-Reply-To: <9e4733910609131438n686b6d72u4d5799533c7473d7@mail.gmail.com>

Jon Smirl wrote:

Show 5 quoted lines

> On 9/13/06, Markus Schiltknecht <markus@bluegap.ch> wrote:
>> Martin Langhoff wrote:
>> > On 9/14/06, Jon Smirl <jonsmirl@gmail.com> wrote:
>> >> Let's copy the git list too and maybe we can come up with one importer
>> >> for everyone.

That would be great.

Show 6 quoted lines

> AFAIK none of the CVS converters are using the dependency algorithm.
> So the proposal on the table is to develop a new converter that uses
> the dependency data from CVS to form the change sets and then outputs
> this data in a form that all of the backends can consume. Of course
> each of the backends is going to have to write some code in order to
> consume this new import format.

Frankly, I think people are getting the priorities wrong by focusing on the format of the output of cvs2svn. Hacking a new output format onto cvs2svn is a trivial matter of a couple hours of programming.

The real strength of cvs2svn (and I can say this without bragging because most of this was done before I got involved in the project) is that it handles dozens of peculiar corner cases and bizarre CVS perversions, including a good test suite containing lots of twisted little example repositories. This is 90% of the intellectual content of cvs2svn.

I've spent many, many hours refactoring and reengineering cvs2svn to make it easy to modify and add new features. The main thing that I want to change is to use the dependency graph (rather than timestamps tweaked to reflect dependency ordering) to deduce changesets. But I would never think of throwing away the "old" cvs2svn and starting anew, because then I would have to add all the little corner cases again from scratch.

It would be nice to have a universal dumpfile format, but IMO not critical. The only difference between our SCMs that might be difficult to paper over in a universal dumpfile is that SVN wants its changesets in chronological order, whereas I gather that others would prefer the data in dependency order branch by branch.

I say let cvs2svn (or if you like, we can rename it to "cvs2noncvs" :-) ) reconstruct the repository's change sets, then let us build several backends that output the data in the format that is most convenient for each project.

Michael