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

----- Original Message -----

From: "Jakub Narebski" <redacted>
To: "Stephen Bash" <redacted>
Sent: Thursday, October 21, 2010 2:37:07 PM
Subject: Re: Converting to Git using svn-fe (Was: Speeding up the initial git-svn fetch)

quoted

quoted

Of course, "ignoring merges" is temporary and a total cop-out

This is still bugging me... Even with svn mergeinfo (which I think
is a small percentage of the SVN revisions in the world),

From what I understand to have svn:mergeinfo you have to have version

quoted

= 1.5 of Subversion installed on server, and to use it also >= 1.5

client.

Correct.  I can't find a release date for 1.5, but my impression is a lot of history in SVN repositories pre-dates 1.5 (especially since it required *both* the client and the server to be updated).  That impression is mostly based on my own experience...  Using Subversion heavily from 2003 to late 2009 my memory is mostly of 1.3 and 1.4 -- I probably only upgraded if I was setting up a new machine or some fancy new tool I was using required the newest version.
 

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.

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

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

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

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

Thanks,
Stephen