Re: CVS -> SVN -> Git

Eric S. Raymond wrote:
> Michael Haggerty <mhaggeralum.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

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribecvs2svn.tigris.org
For additional commands, e-mail: dev-helpcvs2svn.tigris.org

Michael Haggerty <mhaggeralum.mit.edu>:
> 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!

OK, that's a fair point.  I might have known the showstopper
would be
somewhere near Subversion's tags-are-directories assumption.
 And this
also neatly explains why I didn't see any problems or poor
performance
during my recent conversions; the projects I was lifting had
no tags.

> 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.

Or...wait for it...the generator for the serialized format
could be one
of the back ends!   Probably a good idea to have for
debugging reasons, 
if nothing else.
-- 
		<a href="http://www.ca
tb.org/~esr/">Eric S. Raymond</a>

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribecvs2svn.tigris.org
For additional commands, e-mail: dev-helpcvs2svn.tigris.org