Eric S. Raymond wrote: > In slightly more detail: I just finished forward-porting sccs2rcs to > Python, I've been moving some Subversion-hosted stuff to Mercurial, > and I've been thinking about writing a simple rcs2svn because the last > time I tried using cvs2svn on a large RCS history (the Jargon File, as > it happens, a couple years back) it did a very poor job of coalescing > related commits without the CVS metadata. I'm going to hope 2.0.0 has > fixed that; I'll experiment and see. Could you give a quick summary of the relevant differences between CVS and RCS files in this context? Then I'd be happy to try to figure out how bad the situation still is today, and whether it can be easily improved. > [...] > So, I hear about plans to make cvs2svn generate something other than > Subversion, and here's my instant reaction: > > DON'T DO IT! > > This is not because I think Subversion is some kind of final answer to the > VCS problem. Fame from it -- I'm moving towards Mercurial. No, the > real reason I think this would be a waste of time is subtler than that. > > Subversion, by design, is very good at capturing the metadata from > SCCS and RCS and the various CVS variants floating around. In fact, > lifting from those into Subversion is basically lossless - the real > problems are that (a) as Michael notes, the data you're losslessly > lifting is scratchy, and (b) as I've noted, you have to use heuristics > to coalesce file histories into changesets and those don't always make > the links they should. > > That being the case, two-step conversion with tools that import CVS to > SVN and export from SVN to whatever actually works extremely well. Other people have complained about having to convert from SVN to distributed SCMs, because the SVN model doesn't map so easily to their favorite. You are basically suggesting that an SVN repository is the best lingua franca of the SCM world, which I don't believe. The CVS history *does* have to be deformed a bit to fit into SVN, and an svn2xxx converter would have to undo the deformation. My idea is not to built (for example) cvs2git; rather, I'd like cvs2svn to be split conceptually into two tools: cvs2<abstract_description_of_cvs_history>, whose job it is to determine the most likely "true" CVS history based on the data stored in the CVS repository, and <abstract_description_of_cvs_history>2svn Then later write <abstract_description_of_cvs_history>2git <abstract_description_of_cvs_history>2hg etc. The first split is partly done in cvs2svn 2.0. And I naively imagine that writing the new output back ends won't be all that much work. 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
