On Tue, 2011-08-30 at 18:00 +0100, Philip Martin wrote: > Paul Burba <ptbu...@gmail.com> writes: > > > Could you provide some examples of when 'things start to go wrong when > > you next try to use "automatic" merges between the branches'? Was > > there a particular use-case (or cases) you had in mind, or just a > > general sense that maybe this is/could be a problem? > > Here's one (shorter recipes are possible):
Yes, this is exactly the sort of thing I mean. What I expect in general is that if I have merged the same change into both branches, then an automatic (catch-up) merge would do nothing with that particular change. But here we reverse-merge the same change into both branches, and then a catch-up merge raises a conflict on that change. The description of issue #2881 "Support negated mergeinfo revision ranges" says it's concerned about a missing child in the merge target, but what I'm talking about is more general. When I first started thinking about recording reverse merges I worried about crazy complexities: "How would we record a reverse-merge of some change that isn't already in the target's mergeinfo because it wasn't brought in by a merge in the first place? Isn't that rather like trying to teach the merge tracking to record an arbitrary diff that might come from anywhere and might not share ancestry with the target? What if we reverse-merge a change that Subversion doesn't know is there, only the human knows it's there - does the number-of-merges of this change go from 0 to -1? Then if we forward-merge and reverse-merge that same change several times, between each merge doing more hand-editing that Subversion doesn't know about, does the count go from -1 to 0, -1, 0, 1, 0, -1, -2, -1, 0, 1, 2, 3, 2, ...?" But then I realized that's totally unnecessary. We don't need and shouldn't even attempt to record anything other than 'We have change C' or 'We don't have change C', for each change 'C'. The only new thing that I think we want here is the ability to record 'We don't have change C' when C is in our own history; where currently we always assume that we DO have each such change. - Julian > #!/bin/sh -e > > svn=svn ; svnadmin=svnadmin ; svnlook=svnlook ; svnmucc=svnmucc > repo=repo ; wc=wc ; url=file:///`pwd`/$repo > rm -rf $repo $wc > $svnadmin create $repo > > # Create first branch > $svn mkdir -mm $url/A > $svn co $url/A $wc > > # Create second branch from first > $svn cp -mm $url/A $url/X > $svn sw $url/X $wc > $svn merge ^/A $wc > $svn ci -mm $wc > > # Change on second branch > $svn mkdir -mm $url/X/x > R1=`svnlook youngest $repo` > > # Catchup merge first-to-second > $svn sw $url/X $wc > $svn merge ^/A $wc > $svn ci -mm $wc > > # Reintegrate merge second-to-first > $svn sw $url/A $wc > $svn merge --reintegrate ^/X $wc > $svn ci -mm $wc > > # Keep-alive merge first-to-second > R=`svnlook youngest $repo` > $svn sw $url/X $wc > $svn merge --record-only -cr$R ^/A $wc > $svn ci -mm $wc > > # Reverse merge change on second NOT RECORDED > $svn sw $url/X $wc > $svn merge -c-$R1 ^/X $wc > $svn ci -mm $wc > > # Reverse merge change on first RECORDED > $svn sw $url/A $wc > $svn merge -c-$R1 ^/X $wc > $svn ci -mm $wc > > # Catchup merge CONFLICT > $svn sw $url/X $wc > $svn merge ^/A $wc >
