[GSoC update] git-remote-svn: Week 13

[GSoC update] git-remote-svn: Week 13

[Ramkumar Ramachandra]

Hi,

It looks like I've hit a wall with the dumping functionality in
svnrdump- it's merged in cleanly with tests to show where it passes
along with others that highlight the places that it fails. We've
determined that it cannot do better until the underlying
infrastructure (RA layer) is improved, so I've finally stopped working
on this. The dumpfile that it produces is completely valid, but
doesn't match exactly with the dumpfile that `svnadmin dump`
produces. Since Junio has recommended that I don't get svnrdump merged
into git.git, I'll maintain an out-of-tree version that compiles
against Subversion 1.6; however, git-remote-svn will have to spawn the
executable instead of just including a header and using the API that
it exposes atleast until the next Subversion release.

With my subcommand patch merged in, I've removed my svnrload branch
and started working on the "load" subcommand directly in trunk. The
functionality I expect to implement is "svnrdump load" -- it'll read a
dumpfile from stdin and commit the revisions that it represents to a
specified remote repository. Unfortunately, this is quite non-trivial,
and I'm working *really* hard to try and finish this before the end of
the SoC term. I've found a tool called svnmucc in the trunk that I can
use as reference while writing this.

svn-fe itself is in excellent shape in `pu` (thanks to Jonathan's
extensive cleanup and re-roll it while I was flying halfway across the
world) . I expect that it'll make it all the way to `master` without
any issues.

Although I've finished implementing an svndiff0 parser, I'm having
trouble integrating it into svn-fe; I'm currently attempting to
refactor the line_buffer library in svn-fe to load the diff into
memory all at once so that I can apply it. I've determined that unless
someone else helps out, I might not be able to finish this within the
timeline of the SoC (related: my email earlier this week calling for
manpower) and get it merged.

To make svn-fe filesystem-aware, a LOT of refactoring is required. In
short, when a blob is required, it should issue an `M 040000 <SHA1>`
to `git-fast-import` (see 334fba656b50 in `pu`) to fetch the right
tree object when an SVN copyfrom is seen. To be able to do this
however, it has to know the SHA1 of all the commits that it passes to
git-fast-import: this information must come from git-fast-import. It
needs another patch to print the SHA1 of the commit objects everytime
it finishes writing a commit. Related to this, there's a discussion
about how loose objects in the Git store aren't inaccessible by
callers (and how cat-file can be used in fast-import?). Again, I will
personally not be able to handle this in the SoC term.

-- Ram