Hi Eric,
Greg Stein writes:
> We have an import/export format that has existed since svn 1.0, and
> that is our dumpfile format. I do not think we are "required" or need
> to be "shamed" into supporting additional formats.
>
> And for what it's worth, a *git* GSoC student wrote a remote dumpfile
> generator to feed into git's fast-import. We gave the guy commit
> access to *our* trunk and let him build the tool.
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"
We have also finished building a converter from dumpfilev3 -> git
fast-import stream, and are currently working on building the
reverse. That way, there should be no bias and people should be able
to move into Subversion as easily as they can move out of it.
At most, you could criticize the fact that we weren't able to build it
earlier/ faster. Yes, it was a very non-trivial task (atleast for me).
> Also: we have extended our diff generation to support git's diff markers.
Indeed. Daniel did this as part of another GSoC project. `svn diff
--git` works perfectly now.
> In short, there is NO WAY anybody can say we have something against
> git. If somebody came along with code to deal with git's streams, then
> we'd consider it, and the utility it may provide over our own dumpfile
> format.
Since Subversion already has so much infrastructure to deal with
deltified dumpfile, I'd vote to keep that as the native import/export
format.
-- Ram
Received on 2010-11-30 10:41:22 CET