Re: Converting to Git using svn-fe (Was: Speeding up the initial git-svn fetch)
----- Original Message -----
Show 11 quoted lines
> From: "Jakub Narebski" <jnareb@gmail.com>
> To: "Stephen Bash" <bash@genarts.com>
> 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.
> This is quite different
> from merge, where you find comon ancestor and then perform 3-way merge
> (ours, theirs, ancestor).
> 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.
Show 9 quoted lines
> > > 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.
Show 15 quoted lines
> > 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.
Show 14 quoted lines
> > 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.