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

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

[Ramkumar Ramachandra]

Hi,

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?

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

-- Ram

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

[David Michael Barr]

Hi,

> 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.

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

[Sverre Rabbelier]

Heya,

On Thu, Aug 5, 2010 at 09:43, David Michael Barr
<david.barr@cordelta.com> wrote:
> The reason being that going from git to subversion there is a
> general increase in redundant data.

I don't understand?

> On the other hand, to produce an svn dump stream we may need
> to repeat elements encountered earlier in the fast-export stream.

What do you mean with this?

-- 
Cheers,

Sverre Rabbelier

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

[David Michael Barr]

Hi,

>> The reason being that going from git to subversion there is a
>> general increase in redundant data.
> 
> I don't understand?

The primary issue is a blob may be repeated in a non-copy operation,
requiring its content to be described again. This sort of operation only
happens 20% of the time with the ASF repository. We would have to
either write out the content again or compute a new delta depending
on the target version of the svn dump stream.

>> On the other hand, to produce an svn dump stream we may need
>> to repeat elements encountered earlier in the fast-export stream.
> 
> What do you mean with this?

See above, there was some redundancy in my post.

--
David Barr.

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

[Sverre Rabbelier]

Heya,

On Thu, Aug 5, 2010 at 17:15, David Michael Barr
<david.barr@cordelta.com> wrote:
> The primary issue is a blob may be repeated in a non-copy operation,
> requiring its content to be described again. This sort of operation only
> happens 20% of the time with the ASF repository. We would have to
> either write out the content again or compute a new delta depending
> on the target version of the svn dump stream.

Ah, you mean that there might be a "'M' SP <mode> SP <dataref> SP
<path> LF" line in a non-copy operation. It should probably be not
that hard to teach git fast-export to not do that.

-- 
Cheers,

Sverre Rabbelier