[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] Re: cvs import
From: |
Michael Haggerty |
Subject: |
[Monotone-devel] Re: cvs import |
Date: |
Thu, 14 Sep 2006 07:36:56 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.5) Gecko/20060728 Thunderbird/1.5.0.5 Mnenhy/0.7.4.666 |
Jon Smirl wrote:
> On 9/13/06, Markus Schiltknecht <address@hidden> wrote:
>> Martin Langhoff wrote:
>> > On 9/14/06, Jon Smirl <address@hidden> wrote:
>> >> Let's copy the git list too and maybe we can come up with one importer
>> >> for everyone.
That would be great.
> 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
- [Monotone-devel] Re: cvs import, (continued)
- [Monotone-devel] Re: cvs import, Martin Langhoff, 2006/09/13
- [Monotone-devel] Re: cvs import, Michael Haggerty, 2006/09/14
- [Monotone-devel] Re: cvs import, Jon Smirl, 2006/09/14
- [Monotone-devel] Re: cvs import, Michael Haggerty, 2006/09/14
- [Monotone-devel] Re: cvs import, Martin Langhoff, 2006/09/14
- [Monotone-devel] Re: cvs import, Michael Haggerty, 2006/09/14
- [Monotone-devel] Re: cvs import, Jon Smirl, 2006/09/14
- [Monotone-devel] Re: cvs import, Martin Langhoff, 2006/09/14
- [Monotone-devel] Re: cvs import, Markus Schiltknecht, 2006/09/13
- [Monotone-devel] Re: cvs import, Jon Smirl, 2006/09/13
- [Monotone-devel] Re: cvs import,
Michael Haggerty <=
- [Monotone-devel] Re: cvs import, Shawn Pearce, 2006/09/14
- [Monotone-devel] Re: cvs import, Jakub Narebski, 2006/09/14
- [Monotone-devel] Re: cvs import, Shawn Pearce, 2006/09/14
- [Monotone-devel] Re: cvs import, Jon Smirl, 2006/09/14
- [Monotone-devel] Re: cvs import, Michael Haggerty, 2006/09/14
- [Monotone-devel] Re: cvs import, Jakub Narebski, 2006/09/14
- [Monotone-devel] Re: cvs import, Jon Smirl, 2006/09/14
- Re: [Monotone-devel] Re: cvs import, Nathaniel Smith, 2006/09/14
- [Monotone-devel] Re: cvs import, Markus Schiltknecht, 2006/09/15
- [Monotone-devel] Re: cvs import, Shawn Pearce, 2006/09/15