Michael Haggerty <mhagger@xxxxxxxxxxxx>: > 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.catb.org/~esr/";>Eric S. Raymond</a> - 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
