On Tue, 2011-08-30 at 18:00 +0100, Philip Martin wrote:
> Paul Burba <ptburba_at_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
>
Received on 2011-08-31 13:19:27 CEST