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

On Thu, 21 Oct 2010, Stephen Bash wrote:

Jakub Narebski [off-list ref] wrote:

quoted

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.
 

quoted

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?

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?

quoted

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