Michael Haggerty <mhagger@xxxxxxxxxxxx>: > 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. I found my copy of the bug report, and I misremembered the problem slightly. It turns out to be even more relevant to this discussion than I thought. Thread begins with <20040810031409.GA25564@xxxxxxxxxxx> on 9 Aug 2004. The thread title was "RFC -- enhancing cvs2svn to have a notion of spans of mergeable commits". Your mailing-list archive search can't seem to find it, unfortunately. I'll repost the query iseparately > 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. OK. But I think that if SVN -> X is hard, CVS -> X is going to be harder. > You are basically suggesting that an SVN repository is the best lingua > franca of the SCM world, which I don't believe. Not quite. I'm suggesting it's an appropriate lingua franca for centralized VCSes with branching, e.g. everything pre-Arch. > 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? > 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? -- <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
