Re: [RFC PATCH 0/3] Towards a Git-to-SVN bridge

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Jan 15, 2011, 07:22 UTC
Message-ID: <20110115072211.GB25253@burratino>
In-Reply-To: <1295074272-19559-1-git-send-email-artagnon@gmail.com>

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.