On Fri, 22 Oct 2010, Stephen Bash wrote: > ----- Original Message ----- > > From: "Jakub Narebski" <jnareb@xxxxxxxxx> > > 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. Well, I guess that 'svn merge -rN' (merging in a single revision) works similarly to how git-cherry-pick works. > > 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. > > > > 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. > > > 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). > > > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html