Re: CVS -> SVN -> Git

[Michael Haggerty <mhagger@alum.mit.edu>]

Eric S. Raymond wrote:
> Michael Haggerty <mhagger@alum.mit.edu>:
>>                                               The CVS history *does*
>> have to be deformed a bit to fit into SVN, and an svn2xxx converter
>> would have to undo the deformation.
> 
> Then perhaps the right thing to think about is this: how exactly does
> CVS history need to be deformed, and is there some way to express the
> lost information as conventional properties or tags?

Hmmm, perhaps "deformed" was not the best word.  "Reorganized" is a
better description.

For example, cvs2svn internally deduces which files should be added to a
given branch in a given commit.  But the information cannot be output to
SVN in that form.  Instead, cvs2svn has to figure out which
*directories* to copy to the branch directory, then which files to
remove from the copied directory (because they shouldn't have been
tagged), and which other files to copy from other sources.  This extra
work, which is quite time- and space-consuming, is worse than pointless
when converting to git, because git has to invert the process to figure
out which individual files have to be tagged!

>> My idea is not to built (for example) cvs2git; rather, I'd like cvs2svn
>> to be split conceptually into two tools:
> 
> Well, that makes more sense.  But how would whatever the first half outputs
> be different from an svn dump file? 

The interface between the two halves does not necessarily need to be a
serialized data stream; it could just as well be via the Python API that
is used internally by cvs2svn to access the reconstructed commits and
supporting databases.  This would require the second half to be written
in Python, but otherwise would be very flexible and would avoid the need
to find a be-all serialized format.

Michael