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

On Fri, 22 Oct 2010, Stephen Bash wrote:

----- Original Message -----

quoted

From: "Jakub Narebski" <redacted>

quoted

Ah, I understand now that 'svn merge' (which is rather like 'cvs
update') can be used for cherry picking.

Sidenote: in Git cherry picking picks up change and applies it on top
of current branch as one would apply a patch.

Yes.

quoted

This is quite different
from merge, where you find comon ancestor and then perform 3-way merge
(ours, theirs, ancestor). 

Yes.

Well, I guess that 'svn merge -rN' (merging in a single revision) works
similarly to how git-cherry-pick works.
 

quoted

Is merging in Subversion using 3-way merge
(like 'cvs update -j ... -j ...' is), or re-applying changes?

Appears to the be 3-way merge if I'm reading the SVN archives correctly:
  "It's a basic diff3 algorithm. 'man diff3' to learn about it and play 
   with GNU's implementation of diff3."
http://svn.haxx.se/users/archive-2005-03/1232.shtml

So my *guess* is they derive a common ancestor from their copy
information, but I'm sure someone else more knowledgable could say
more about that.  

I guess that in Subversion <= 1.4 it takes N in 'svn merge -rN:M' as an
ancestor version for 3-way merge, and that in Subversion >= 1.5 it takes
last merged in state (from 'svn:mergeinfo' property[1]) if branch is 
merged subsequent time, or first common revision for both branches[2]
if it is first merge.

[1] The 'svn:mergeinfo' is about "merged-in tracking" rather than about
    "merge tracking".  Though change in 'svn:mergeinfo' indicates a 
    merge commit.

[2] I guess this is to be able to find such common ancestor (common
    revision) on first merge is the reason why merging branch into trunk

         .---B---.---.---.---M---.
              \             /
               \---.---.---/

    and merging trunk into branch

         .---B---.---.---.---.---.
              \           \  
               \---.---.---M---.

    needs a manual (by the way of '--reintegrate' option) distinguishing.
 

quoted

quoted

quoted

I have read some documentation about svn:mergeinfo property:
http://svnbook.red-bean.com/en/1.5/svn.branchmerge.basicmerging.html

I guess this the first time I've read the 1.5 version of the SVN
Book.
This has consequences below...

Errr... what consequences? a:b vs a-b being closed (inclusive) or open
(exclusive) from one or other end?

No, just that post-1.5 merges do actually start to look more like Git
merges. 

Well, at least they can be unambigously detected, instead of relying on
parsing commit message of merge commit.
 

quoted

quoted

Back to the task at hand... having read the 1.5 SVN docs, I have no
idea how this works now (big caveat!!!), but prior to 1.5 M1 would
have been

  svn switch svn://path/to/foo
  svn merge -ra:b svn://path/to/bar destination-path

which is "Take the changes introduced in revisions a through b, and
apply them to the destination-path". This is why I think of SVN
merges as cherry-picks -- I was allowed to specify exactly what
changesets I wanted merge to work on.

On one hand side you "were allowed to specify exactly what changesets
you wanted to merge to work on", on the other hand side you *had* to
specify what changesets etc.

My point is because the user was required to specify the revisions
to merge, I don't think an automated tool (i.e. the mapper) can make
assumptions about what was actually merged in any given revision.  

The problem is with even detecting that it was a merge and not ordinary
commit (well, unless some commit convention was used for merge commits,
but how likely that is that it was applied thoroughly, consistently, and
without mistakes that would trip a parser of a merge detector).
 

quoted

quoted

To truly illustrate this, consider a' is in between a and b:

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

I could

  svn switch svn://path/to/foo
  svn merge -ra':b svn://path/to/bar destination-path

and "a" would never be merged back to foo.

Such merge would be hard to represent in Git, I think.

I agree.

Well, at least in a way that merge in git would consider the same 
revisions as already applied as Subversion would when merging.

-- 
Jakub Narebski
Poland