David Frech wrote: > I have a modest svn repo (about 800 commits) that contains fifteen or > so small projects. It started life as a CVS repo, and as the projects > grew and changed, and as I learned more about CVS, things got moved > around. Later, when I got interested in svn (in 2005) I converted the > repo, using cvs2svn. It got a few things wrong - mostly, that it > thought there was one project in the repo, and created toplevel > trunk/, branches/, and tags/ directories, and lumped everything below > these. I know this tangential to the main point of your post, but BTW multiproject conversions were added to cvs2svn in release 1.5. > It took a day and half to get the svn dump parsing right (it's an > egregiously bad format) but only a couple of hours to write the > fast-import backend. I'm surprised you think that; I find the svn dump format quite easy and straightforward. (Of course it assumes some Subversionisms, like easy deep directory copies, which I can imagine would be annoying in other contexts.) What don't you like about the format? > Having done all this, I realized that this is a good way to go. > Separating, as Michael suggests, the "parsing" part from the "commit > generating" part, not only makes the tools easier to write, but makes > them more flexible. If hg or bzr had a git-like fast-import (maybe > they do) it would take me about 35 minutes to target that instead. And > in the process I came across some "missing features" in fast-import, > which Shawn Pearce was able to quickly add. Yes, fast-import is a very easy-to-write format and looks to be very well documented. I don't think that having to write output in fast-import format would be any kind of a hindrance for such a tool. 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
