Jon Smirl wrote: > On 9/13/06, Markus Schiltknecht <markus@xxxxxxxxxx> wrote: >> Martin Langhoff wrote: >> > On 9/14/06, Jon Smirl <jonsmirl@xxxxxxxxx> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html