Hi Jonathan, Jonathan Nieder writes: > 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: Thanks for raising these questions. People interested in the project should find this useful. > - what are the design goals? Is this meant to be super fast? > Robust? Simple? Why should I be excited about it?[1] I want it to be a lot like current svn-fe: as you can see, I've re-used many parsing ideas from it. It has to be atleast as fast as svnrdump, because I don't want it to bottleneck in the remote helper pipeline. It has to be simple because it'll give rise to other simple remote helpers- all the complexity has to be offloaded onto the lower layers like fast-import/ fast-export, and not onto the developer of the remote helper. > - what subset of fast-import commands is supported? Is it well > enough defined to make a manpage? Currently, it supports just "commit", "blob", "author", "committer" and "mark" that appear after a blob. It should support more commands soon enough- this implementation is just a proof of concept. Also, Instead of giving it the ability to parse /any/ valid fast-import stream, I want to simply focus on parsing the stream produced by git fast-export. That should explain why I'm trying to patch git fast-export primarily. > - does this produce v2 or v3 dumpfiles? This is one issue I haven't thought about fully yet. I'm currently thinking of generating a non-deltified dumpfile v3 -- something that svnrdump will accept. Generating deltas might be an unnecessary overhead- but as you pointed out yesterday, that clearly needs more thought. > - 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.) git2svn persists blobs in-memory. It's written in Perl and it's slow. I thought we needed something nicer to be used with a remote helper, and started writing svn-fi. > > I've decided to try re-implementing fast-export > > to eliminate blob marks > > Hopefully "re-implement" means "patch" here. :) Yep. Just a big one :) > 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). I haven't had time to clean up the code. Note that it "just works" at the moment- yes, it's already very very fast :) However, I'm going to stall the branch and work on fast-export-inline for now. -- Ram -- 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