Hi Ram,
Ramkumar Ramachandra wrote:
> Over the last couple of days, I've been working on a parser that
> converts a fast-import stream into a SVN dumpfile. So far, it's very
> rough and works minimally for some common fast-import
> commands.
Some early questions:
- what are the design goals? Is this meant to be super fast?
Robust? Simple? Why should I be excited about it?[1]
- what subset of fast-import commands is supported? Is it well
enough defined to make a manpage?
- does this produce v2 or v3 dumpfiles?
- why would I use this instead of git2svn? Does git2svn do anything
this will not eventually be able to do? (Not a trick question ---
I don't have enough experience with git2svn to tell its strengths
and weaknesses.)
> I've decided to try re-implementing fast-export
> to eliminate blob marks
Hopefully "re-implement" means "patch" here. :)
I can comment on the code but it's probably better if I have a sense
of the design first (in any event, thanks for sending it).
Regards,
Jonathan
[1] I found the original svn-fe design interesting because
(1) it reused code from an existing svndump parser, at least in
spirit,
(2) the repo_tree data structure was well fitted to the design
constraints,
(3) the line_buffer input abstraction was oddly satisfying, even
though it does not buy anything obvious out of the box over
direct use of strbuf and stdio;
(4) speed; and, most importantly
(5) the command-line interface was easy to debug, very flexible,
and dead simple.
I find the current svn-fe satisfying in a different way --- a sort of
"line by line" translation between dump formats is becoming possible.
--
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