[PATCH] convert: make convert from cvs recognise branch points correctly [revised, 3]

Patrick Mézard pmezard at gmail.com
Tue Apr 21 09:25:33 CDT 2009


Michael Haggerty a écrit :
> 
> I'm not so familiar with the cvsps.py code, but I have been working on
> cvs2svn/cvs2git/cvs2hg [1] for years so I know a lot of things that can
> go wrong with a CVS conversion.
> 
> Date clustering doesn't work robustly because CVS fundamentally has a
> file-by-file view of the world.  It is quite common to see things like
> the following:

[snip]

> There is no way to know without more information.  It is also possible
> that a and/or c were never even added to the branch.

Interesting.
 
> I encourage you to read the cvs2svn design documentation [1] and
> features list [2] to see what we finally had to do to get a conversion
> that is consistent with the CVS history.  The key is that the original,
> naive changesets (i.e., equivalent to cvsps's *final* changesets :-) )
> often have to be broken up in order to break cycles in the dependency
> graph and allow the topological sort to succeed.  Otherwise the
> conversion will be *objectively wrong* in the sense that the content
> checked out of hg simply doesn't agree with what is checked out of CVS.

I have no doubt that cvs2svn is way more reliable than cvsps.
 
> I would also like to remind Mercurial users that cvs2svn [3] has a
> "cvs2hg" mode (please use the current SVN version) that outputs data
> that can be loaded by Mercurial's fastimport extension.  I could use a
> little help from the Mercurial community to make sure that the
> conversion is "idiomatic" for the hg world.  But the reconstruction of
> the CVS history is very robust, as it shares (literally, I just measured
> it) 97% of its code with cvs2svn.  And it's even written in Python :-)

IIRC, someone wanted to revive hgfastimport. I guess what you really need is a bit of marketing, starting with the wiki. Adding a link from the convert page would be a good start.

> If it would help convince people to help develop and use cvs2hg instead
> of working on Mercurial's CVS convert extension, I am confident that I
> can quickly cook up some test cases that cause the hg convert extension
> to break in ways that are nearly impossible to fix.  (I recently "helped
> out" the git project this way [4,5].)

Again I have no doubt about that.

BUT:

Unless csv2svn learnt to do incremental conversions, both tools does not solve the same problem space. Most of the conversion stories I heard happened by mirroring the historical repository in Mercurial, so people can grow accustomed to it and make their decision. You cannot really do that without incremental conversions, and my bet is, given all the smarts you put in cvs2svn, it would be that much harder to make it incremental.

If I had to migrate from CVS, I would actually use both: convert extension to avoid the leap of faith, cvs2svn for it's known to make good conversions.

Finally, I would be happy to see cvs2svn work incrementally, if it does not already (shame on me in this case) :-)

--
Patrick Mézard


More information about the Mercurial-devel mailing list