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

[Jakub Narebski <jnareb@gmail.com>]

On Thu, 21 Oct 2010, Stephen Bash wrote:
> Jakub Narebski <jnareb@gmail.com> wrote:


> > But because Subversion doesn't impose strict separation between branch
> > namespace and in-repository paths, somebody somewhere would certainly
> > at some time screw this up. And only then we would have to rely on
> > subtree merge / git-subtree split similarity detection.
> 
> I don't have much experience with subtree merge...  It's possible
> that will improve the situation. 

I mean here the method used by "subtree" merge strategy, not by subtree
merge itself, i.e. the mechanism which make git apply changes to subtree
merged subproject at correct place.
 
> > BTW. Subversion doesn't have "svn cherry-pick", nor equivalent to
> > "git reset" == "git cherry-pick -R"... well, at least I don't think it
> > has.
> 
> See below...

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?


> > 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?

> > ---1---B---2---3---M1--4---5---M2 <-- foo
> >         \         /           /
> >          \-a---b-/-----c---d-/ <-- bar
> > 
> > B is branching point, M1 and M2 are merge commits.
> > 
> > In Git, and I assume that also in Subversion, when doing merge M1, the
> > VCS notices that from revision B branches 'foo' and 'bar' have common
> > commits (in git we say that merge base of 'foo' and 'bar' at the point
> > of doing merge M1 is commit B). 
> 
> I'm going to take a little liberty with SVN revisions because I've
> always thought of SVN revisions as before and after the change, so a:b
> in SVN is the change introduced in b, but since we're on the Git list,
> in the following examples I will use a:b to mean the changes
> introduced in both a and b.  (Since it was introduced, I've always
> read "svn diff -c rev" as "svn diff -r rev-1:rev")
 
"git show rev" always show changes to parent, i.e. the same as 
"git diff rev^ rev" (rev^ ~= rev-1, if rev is not 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.

So it was "make branching easy and O(1)"... and they forgot that
branching standalone doesn't make much sense, and that easy *merging*
is also required.  Merging in pre 1.5 times is as bad as in CVS.

> 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.

> The concept of *not* specifying revision numbers to merge is new
> in 1.5. See  
> 
>   http://svnbook.red-bean.com/en/1.4/svn.branchmerge.copychanges.html
> 
> This is what scares me about mapping SVN merges to Git merges.  It
> seems post-1.5 merges have a lot more in common with Git than pre-1.5
> (though mergeinfo is still brain damaged -- easy branching and merging
> is why I switched!), but I think we still need to support pre-1.5.   

-- 
Jakub Narebski
Poland