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

[Jonathan Nieder <jrnieder@gmail.com>]

Jonathan Nieder wrote:

> Git has all the blobs and all the trees, so except for the mapping
> between marks, subversion revs, and git revs, svn-fe does not need to
> persist much data at all.
> 
> Of course, that requires that the fast-import stream is going directly
> to git.

One more thought.

If we are tracking the history of separate subversion branches separately,
then reading back trees includes an oddity:

Suppose someone tries to reimplement git-svn on top of svn-fe[1].

 $ git svn --fe clone --stdlayout http://path/to/some/svn/root

Behind the scenes, git-svn processes the fast-import stream it is
receiving and writes its _own_ fast-import stream with paths munged
and commits split up into separate commits on each branch.  Good.

Now the oddity: suppose that in the repository, svn-fe finds an

 svn copy branches@r11 branches-old

operation.  In other words, it needs the tree for
http://path/to/some/svn/root/branches@r11.  This does not correspond
to a single git tree, since the content of each branch has been given
its own commit.

However, this does not seem to be fatal: one could just make
‘git svn --fe’ build a branch with the full history at the same time
as it builds the other branches.  Ugly, but I don’t see another way
around it without making svn-fe and ‘git svn --fe’ know more about
each other than I would like.

Jonathan

[1] Eric, we are discussing the remote-svn series[2] and especially
Ram, Sverre, and David’s recent comments[3].  Apologies for not
keeping you in the loop sooner; your insights have always been
helpful in the past.

As for the idea of reimplementing git-svn on top of svn-fe: yes, the
fast-import stream would need more information to support
--follow-parent, but that piece is not so hard to add AFAICT.  Of
course, I am mentioning this not because it is important to keep the
git-svn interface but because the --stdlayout feature is very useful
and we may want to port it over some day.

[2] http://thread.gmane.org/gmane.comp.version-control.git/149571
[3] http://thread.gmane.org/gmane.comp.version-control.git/149594