Re: GSOC Proposal draft: git-remote-svn

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Apr 2, 2012, 23:04 UTC
Message-ID: <20120402230452.GE13969@burratino>
In-Reply-To: <20120402205659.GA13725@burratino>

Jonathan Nieder wrote:

>  - Importing <rev, path> pairs that have multiple parents.  In the
>    subversion model, path nodes have only one (copyfrom) parent,
>    but repositories can use the svn:mergeinfo property to indicate
>    that changes made in certain revs to another patch have been

The above should say "... changes made in certain revs to another _path_ ...".

>    incorporated.  Under what circumstances is that enough
>    justification to add a second parent on the git side?

One subtlety here is that sometimes people merge almost everything from some branch but leave a few revisions out. Imagine the following history:

 o --- B1 --- B2 --- B3 ---- B4 -- F' ---- B6 --- B7 --- B8 [branch]
  \                                 \                     \
   \                                 \                     \
    T1 --- F ------------------------ M1 ------------------ M2 [trunk]

The bugfix F was applied to the trunk first and then applied to the branch as rev F'. Then the maintainer merged the remaining changes B1, B2, B3, B4 from the branch to trunk. In git this operation would be carried out by running "git merge branch". Finally some more changes were made on the branch and the maintainer merged those to trunk, too.

In subversion, this could be done like so:

 1. Make commit T1 on trunk.
 2. Make commit F on trunk.
 3. Make commits B1, B2, B3, B4 on branch.
 4. Make commit F' on branch, either using "svn merge" or by hand.
 5. Merge changes B1, B2, B3, B4 from branch to trunk using
    "svn merge -r o:B4 <url for branch>" and commit.
 6. Make commits B6, B7, B8 on branch.
 7. Merge changes B6, B7, B8 from branch to trunk using
    "svn merge -r F':B8 <url for branch>" and commit.

The resulting svn:mergeinfo property on trunk in revision M1 would look like this:

	/branches/branch:B1-B4

To a naive importer, this looks like a merge of B4. The svn:mergeinfo property on trunk in revision M2 would look like this:

	/branches/branch:B1-B4,B6-B8

which looks like a bunch of cherry-picks rather than a merge, since it looks like this almost-merge leaves out F'.

If the maintainer used "svn merge --reintegrate" instead, the svn:mergeinfo properties are a little simpler, so maybe I am worrying for no good reason. Anyway, hopefully that makes the setup a little clearer.