Re: [GSoC update extra!] git-remote-svn: Week 13

From: David Michael Barr <david.barr@cordelta.com>
Date: Aug 5, 2010, 14:43 UTC
Message-ID: <0C6B8C5E-15BA-43AD-B2F2-914F39EA6046@cordelta.com>
In-Reply-To: <20100730190124.GA2995@kytes>

Hi,

Show 8 quoted lines

> I just got a proof-of-concept loader for Subversion working. It just
> about works for a very small reduced case. I'll still have to hammer
> it into shape for to handle various cases [1]. In the meantime, we
> also have to start working on doing the inverse of what
> svn-dump-fast-export does: convert a Git fast-export stream to a
> Subversion dumpfile.
> 
> David: Can you estimate how challenging the task is going to be?

Ram, sorry for the late reply, I've been rather sick this week.

Assuming that the fast-export stream will be already linearised... I think it will be more complex than svn-fe even with that constraint. The reason being that going from git to subversion there is a general increase in redundant data. While svn-fe preserves much of the redundancy of the original svn dump stream, git is able to eliminate much of it. On the other hand, to produce an svn dump stream we may need to repeat elements encountered earlier in the fast-export stream. We may be able to achieve a simple implementation by placing further restrictions on the form of the fast-export stream.

> [1]: I'm working on it directly in trunk. You can find the latest code
> in subversion/svnrdump in the Subversion trunk.
> 
> -- Ram

On a related note, I've found a defect in the svn dump stream design. Truncation of an svn dump may result in a valid stream with an incomplete trailing commit. Even more fun is that when svnrdump encounters an error in the middle of handling a commit, it will likely produce such a stream. I broked my ASF mirror by loading an incomplete incremental dump. :(

TODO: cross-post the last paragraph to svn-dev.

-- David Barr.