Hi Eric, Eric Raymond writes: > Ramkumar Ramachandra <artag...@gmail.com>: > > Yep, that's completely true. I am that GSoC student, and > > subversion/svnrdump is complete. The Subversion community was > > supportive of it. And yes, I wrote both "dump" and "load" > > functionality. So there is some factual inaccuracy in your statement: > > "Subversion is typical in that it has a proof-of-concept third-party > > exporter that loses some metadata, and no importer" > > Thanks for the information. Where can I find documentation on this > capability? I'm particularly interested in how it handles the two > issues I mentioned - mapping between Subversion's server-loxcal commit > identities and import=-stream's full addresses, and mapping between > Subversion merge-tracking info and the input-stream's commit-ancestry > fields.
`svnrdump (dump|load)` behaves almost exactly like `svnadmin (dump|load)` over the network. The conversion to git fast-import is merged into git.git: the infrastructure is in ^/vcs-svn and a small end-user tool is available in ^/contrib/svn-fe -- usage information is in svn-fe.txt: http://git.kernel.org/?p=git/git.git;a=blob;f=contrib/svn-fe/svn-fe.txt It currently doesn't handle any of the issues you mentioned- we haven't built the mapper yet, and it's just a dumb converter at the moment. We are currently working on some plumbing to support incremental imports, and build a remote helper. After that, we will work on the mapper and the git fast-import -> dumpfile v3 converter to feed `svnrdump load`. Also, there has been a lot of discussion about the mapper on the mailing list, and here's one particularly huge thread: http://thread.gmane.org/gmane.comp.version-control.git/158940/focus=159054 Hope that helps :) > > Since Subversion already has so much infrastructure to deal with > > deltified dumpfile, I'd vote to keep that as the native import/export > > format. > > That decision is orthogonal to what I'm interested in, and I have no > position on it. Ok. -- Ram
