David Frech wrote:
quoted text
> 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.

quoted text
> 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?

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html