git-remote-svn: Week 11

Hi,

I'm happy to report that I'll soon be getting partial committer access to the ASF repository (thanks to Greg for this) and will be able to commit the svnrdump there. At the moment, all the validations pass without any issues and I've shifted my focus towards writing a dumpfile v3 parser [1] to get the data into David's exporter. I will re-roll a series for git.git in some time again after I've fixed a few pending things pointed out by Jonathan in his excellent reviews and merged a few patches from Will; although this isn't top priority, it will be pretty painful for Git developers to compile the SVN trunk even if they want to try out git-remote-svn.

Currently, I'm implementing svndiff0 parser component of the dumpfile v3 parser using Sam's Perl implementation [2] as a guideline. In addition, with an excellent specification present in the Subversion trunk [3], this shouldn't be a problem.

-- Ram

[1]: dumpfilev3 branch of
http://github.com/artagnon/svn-dump-fast-export/
[2]: http://search.cpan.org/~samv/Parse-SVNDiff/
[3]: http://svn.apache.org/repos/asf/subversion/trunk/notes/svndiff

Ramkumar Ramachandra venit, vidit, dixit 12.07.2010 16:35:

While this is certainly true for the "compilation" part, at least getting the source is a snap for us:

git://git.apache.org/subversion.git
git://github.com/apache/subversion.git

:)

Michael

Regarding compilation, take a look at tools/dev/unix-build/Makefile.svn in the Subversion tree. Possibly the most painful thing for git devs is that you'll need an svn binary somewhere in PATH, but any version will do. Then create an empty directory (say, ~/svn), copy the Makefile in there, and run make (requires GNU make). That will download and compile Subversion from trunk, including various dependencies.
If all goes well, binaries (with debug symbols) end up in ~/svn/prefix/

On Linux, -devel packages for a couple of libaries may be needed (most likely openssl, zlib, expat, libproxy).

Stefan

This is all moot, because the whole point is that svndumpr compiles against libsvn, so you don't need the whole svn source-tree. All you need to get svndumpr working are some header files and a working libsvn. Everyone who currently uses git-svn already has a working libsvn, since perl's svn bindings wrap around libsvn anyway.

Hi,

Yes, I meant that people will need the complete Subversion tree if I DON'T get svnrdump merged somewhere in git.git (I'll attempt to get the version that compiles against libsvn 1.6 merged). The instructions to checkout the right branches and place it in the git tree can be
complicated: git-remote-svn relies on a chain of tools including David's exporter and svnrdump to work.

-- Ram

It's not moot. svndumpr may now or in the future be using API calls which are specific to the Subversion 1.7 libraries, in which case you'll need to compile Subversion from trunk to get compatible libraries until 1.7 is released. Maybe Ramkumar wants to maintain a 1.6.x-specific version you can use, but that won't be living in our repository anyway.

Stefan

Stefan Sperling venit, vidit, dixit 12.07.2010 17:24:

That Makefile pulls in (and compiles) a lot of stuff which may or may not be what you want.

In terms of Git development, I prefer a Git checkout (rather than a svn checkout) of the subversion code where I can bisect happily. Fulfilling most dependencies using devel packages was not a real problem (Fedora 13), just an iterative process...

The most painful part is that older svns (e.g. 1.4.6) don't seem to like newer autoconf (2.65) so that compatibility testing gets difficult, especially because (due to the branch structure of the code) merge bases of, say, 1.5.0 and trunk go quite a way back (1.5.0~955).

Michael