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