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

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Jun 24, 2010, 18:07 UTC
Message-ID: <20100624180752.GA1642@burratino>
In-Reply-To: <20100624173956.GA1600@burratino>

Jonathan Nieder wrote:

Show 6 quoted lines

> 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