Eric Raymond writes:
> Ramkumar Ramachandra <artagnon_at_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
`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
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
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.
Received on 2010-11-30 11:20:53 CET