----- Original Message ----- > From: "Jakub Narebski" <jnareb@xxxxxxxxx> > To: "Stephen Bash" <bash@xxxxxxxxxxx> > 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. > > > 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. > > 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. > > 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 -- 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