On Thu, 21 Oct 2010, Stephen Bash wrote: > Jakub Narebski <jnareb@xxxxxxxxx> 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 -- 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