As explained in
http://subversion.tigris.org/issues/show_bug.cgi?id=2973#desc23, using
a reverse merge to revert a change from a path's own history is a
no-op in a (IMHO) common use case, briefly:
You have WC freshly checked out at a uniform revision:
>svn st -v TEST
2 2 pburba TEST
2 2 pburba TEST\trunk
2 2 pburba TEST\trunk\file
You make a change that doesn't affect the root of the WC and commit it:
>echo new content > TEST\trunk\file
>svn ci -m "" TEST
Sending TEST\trunk\file
Transmitting file data .
Committed revision 3.
Oops, you didn't want to do that, revert the change with a reverse merge:
>svn merge %TEST_URL% TEST -c-3
>
Hey, why a no-op? Because the merge target 'TEST' is at working rev
2, and trying to reverse merge a change (r3) that is not in the
target's explicit or natural mergeinfo is not allowed in the braze new
world of merge tracking (see
http://subversion.tigris.org/issues/show_bug.cgi?id=2973#desc26 as to
why this is).
>svn st -v TEST
2 2 pburba TEST
2 2 pburba TEST\trunk
3 3 pburba TEST\trunk\file
This problem is easily remedied by updating the WC (or using
--ignore-ancestry)...
>svn up TEST
At revision 3.
>svn st -v TEST
3 3 pburba TEST
3 3 pburba TEST\trunk
3 3 pburba TEST\trunk\file
>svn merge %url% TEST -c-3
--- Reverse-merging r3 into 'TEST':
U TEST\trunk\file
...but I suspect users will not find this terribly obvious and prior
to 1.5 the reverse merge worked without updating, so this is a
regression of sorts. Originally I had thought that if TEST_at_2 and
%TEST_URL%_at_3 were on the same line of history then just blindly
perform the reverse merge. But cmpilato thought a warning was
preferable, so here is a patch that does just that. Now the above
no-op would give a helpful(?) warning:
>svn merge %TEST_URL% TEST -c-3
svn: warning: Cannot reverse merge a range from a path's own future
history; try updating first
>
Beyond the obvious question of "is the right course of action", I was wondering:
1) Does that error message make sense?
2) Is it ok to use SVN_ERR_CLIENT_NOT_READY_TO_MERGE here or is that
intended only for errors related to --reintegrate?
Paul
[[[
Fix for reopened issue #2973, revert of a changeset rX on a target with merge
history from same target does not work.
A reverse merge to a path from that path's own history may no-op in some
common mixed-rev WC situations. E.g. you make a change in rN then
immediately reverse merge rN. If rN *didn't* affect the merge target, then
the target's working revision is still < N and the merge will no-op. An
update is needed for the reverse merge to work, so give a warning suggesting
this.
* subversion/libsvn_client/merge.c
(calculate_remaining_ranges): Give a warning to the user that an update
might be required to accomplish what they want.
Suggested by: cmpilato
]]]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-14 17:40:04 CET