Re: reverse-merge broken?

On Fri, 19 Oct 2007, Jack Repenning wrote:

> On Oct 18, 2007, at 4:35 PM, Kamesh Jayachandran wrote:
>
> >Jack,
> >
> >Do you have any mergeinfo on a target from the corresponding merge
> >source?
>
>
> Yes:
> > svn plist -vR .
> Properties on '.':
> svn:mergeinfo : /branches/B1:4-16
> /trunk:3-7
> Properties on 'greek':
> svn:mergeinfo :
> Properties on 'greek/iota':
> svn:mergeinfo : /branches/B1/greek/iota:4-16
> /trunk/greek/iota:6-7
>
>
> I merged from branch B1 to (a working copy on) trunk, committed,
> updated, then attempted to reverse that very merge.
>
> >Then only the 'avoid repeat reverse merge code kicks in' and hence
> >no reverse merge.
> >
> >Probably we may need '--merge-insensitive' or '-G' to support
> >repeat reverse merge.
>
> I do not think we need any flags to mean "do the right thing" in this
> case. There is no conceivable other meaning to
>
> svn merge -c-17
>
> than "undo rev 17."
 
r17 isn't listed in the mergeinfo shown above.
Is it the "merged in" revision for some other transitive merge? If not,
you'd want r16 (e.g. 'svn merge -r16:15', rather than 'svn merge -r17:16').
 
> On Oct 18, 2007, at 4:54 PM, Mark Phippard wrote:
> >Since a reverse merge is always going to be an explicit user
> >operation, maybe we ought to just not try to avoid repeat reverse
> >merges? The user has already signified they want to reverse the
> >merge, so why not just try to do it? What is the scenario where this
> >is going to lead to incorrect behavior?
>
> Yes, that would be more reasonable than the present behavior.
>
> Better than both might be:
> 1. look at the svn:mergeinfo for the revision in the -c-XX flag
> 2. find which revisions were added to the branch history by that
> revision
> 3. look in the svn:mergeinfo for the current version
> 4. if the revisions added in #2 are still present, remove them;
> otherwise print/return a warning that the named change set is not in
> this revision, so it can't be removed

Unfortunately, the revision might still be in the target, but simply not
listed in the mergeinfo (e.g. because the merge was performed with a
pre-1.5 client before the userbase migrated to 1.5, and there is no record
of the merge occurring).

We still have to unmerge the revision. I'd be fine with this happening
with or without notification. I don't think a flag is necessary, but if
we do want a flag (-0 for 1.5), I'd suggest re-using --force.

-- 
Daniel Rall