Re: Converting to Git using svn-fe (Was: Speeding up the initial git-svn fetch)

From: Jakub Narebski <jnareb@gmail.com>
Date: Oct 21, 2010, 18:37 UTC
Message-ID: <201010212037.09618.jnareb@gmail.com>
In-Reply-To: <4424833.537061.1287669604786.JavaMail.root@mail.hq.genarts.com>

On Thu, 21 Oct 2010, Stephen Bash wrote:

> Will Palmer <wmpalmer@gmail.com> wrote:

> > Of course, "ignoring merges" is temporary and a total cop-out
> 
> This is still bugging me...  Even with svn mergeinfo (which I think
> is a small percentage of the SVN revisions in the world),

>From what I understand to have svn:mergeinfo you have to have version >=

1.5 of Subversion installed on server, and to use it also >= 1.5 client.

Show 7 quoted lines

> IMO an SVN merge is *not* a Git merge.  I think of it as a git
> cherry-pick (someone correct me if this mental model is wrong).
> The key point in my mind is SVN merge doesn't have to merge the entire
> branch history.  Perhaps some heuristics can be applied in Git to
> decide if an SVN merge is a "true merge" or a cherry-pick?  But I have
> a nagging feeling that in the end the model mismatch is going to be
> very hard to overcome.

Hopefully in most common situations (i.e. SVN repository is not mishandled) the svn:mergeinfo would be _only_ on branch folders ("branches/<branchname>") and inherited downwards. This should be fairly easy, I think, to translate to git merges (merge commits).

But because Subversion doesn't impose strict separation between branch namespace and in-repository paths, somebody somewhere would certainly at some time screw this up. And only then we would have to rely on subtree merge / git-subtree split similarity detection.

BTW. Subversion doesn't have "svn cherry-pick", nor equivalent to "git reset" == "git cherry-pick -R"... well, at least I don't think it has.

......................................................................
Warning! Rant ahead!
<rant skip="if needed">
I have read some documentation about svn:mergeinfo property:
  http://svnbook.red-bean.com/en/1.5/svn.branchmerge.basicmerging.html
  http://www.collab.net/community/subversion/articles/merge-info.html

I see how "branches are folders" model, without a concept of version included in (belonging to) some branch and without the concept of 'previous version in the same line of development' leads to such strange, bizzare things.

First, svn:mergeinfo is not about tracking which commits (which parents) were involved in creating given version, like in Git (where merge commit that was result of merging branch 'bar' into 'foo' has commits which were then tips of 'bar' and of 'foo' as two parents of commit representing result of merge).

No, svn:mergeinfo is ass-backwards solution to the problem that "merge tracking" solves, namely that of repeated merging. Let's take a look at the following situation:

   ---1---B---2---3---M1--4---5---M2   <-- foo
           \         /           /
            \-a---b-/-----c---d-/      <-- bar

B is branching point, M1 and M2 are merge commits.

In Git, and I assume that also in Subversion, when doing merge M1, the VCS notices that from revision B branches 'foo' and 'bar' have common commits (in git we say that merge base of 'foo' and 'bar' at the point of doing merge M1 is commit B). VCS it know then that it has to integrate changes that were made on branch 'bar' since cleft point B, i.e. changes brought by revisions 'a' and 'b', with changes made on branch 'foo' since B, i.e. changes brought by revisions '2' and '3'. Git does that by running 3-way merge (same as rcsmerge / diff3 merge) with '3' as ours aka mine version, 'b' as theirs aka yours version, and 'B' as ancestor aka older version; I assume that Subversion does the same thing, or equivalent.

Now here is where things begin to be different in Git and in Subversion. In Git, commit 'M1' with merge resolution has simply two parents: '3' and 'b'.

In Subversion there is no such thing like parent of revision. Instead of this SVN records that it integrated changes brought by revisions 'a' and 'b' into 'M1', which means that from revision 'M1' the branch folder ("project/branches/foo") acquires svn:mergeinfo property with the contents '/branches/bar:B-b' (B-b is a:b, i.e. range from B to b, excluding B). PLEASE CORRECT ME IF I AM MISTAKEN.

Note branch info in svn:mergeinfo property. Note the revision range instead of just its endpoint 'b'. Note lack of reference to what would be first parent in git merge commit, i.e. '3'.

Let's take a look what happens at point M2 (i.e. second merge) in Git and in Subversion.

In Git it is easy. Git calculates merge base by travelling parentage links (which include all parents of merge commits), and notices that at point 'M2' merge base, i.e. first common ancestor of branches 'foo' and 'bar' is commit 'b'. It then runs 3-way merge with '5' as ours, 'd' as theirs, and 'b' as ancestor, and records merge commit with parents '5' and 'd'.

Subversion instead examines svn:mergeinfo property to check what it already merged in, and somehow notices that it has to integrate changes c+d made on branch 'bar' (but not a+b+c+d, as a+b were already integrated) with changes 4+5 on branch 'foo'. Probably it somehow notices that 'b' is common ancestor. But you can see how this mechanism is fraught with peril and can break easily in more complex situations ("The 1.5 release of merge tracking has basic support for common scenarios; we will be extending the feature in upcoming releases."... they hope!).

Subversion then updates svn:mergeinfo property at branch 'foo'. </rant>

-- 
Jakub Narebski
Poland