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

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

From: "Jakub Narebski" <redacted>
To: "Stephen Bash" <redacted>
Sent: Thursday, October 21, 2010 6:49:32 PM
Subject: Re: Converting to Git using svn-fe (Was: Speeding up the initial git-svn fetch)

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.

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

Yes.

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.

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.

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.

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.
 
Thanks,
Stephen