[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

[PATCH] Warn when attempting to reverse merge range from target's future history

From: Paul Burba <ptburba_at_gmail.com>
Date: Thu, 14 Feb 2008 11:39:54 -0500

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.