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

Support for reverse merges?

From: Julian Foad <julian.foad_at_wandisco.com>
Date: Tue, 30 Aug 2011 17:30:44 +0100

Philip and I were discussing the other day...

It seems that we don't consistently record a reverse merge. Sometimes
we do, sometimes we don't.

  * Iff this branch's mergeinfo mentions the change that we're
reverse-merging, then we remove the mention from the mergeinfo and so
merge tracking can notice that the change is no longer recorded as being
there. (And a further catch-up merge will bring in that original change
again. For the purposes of this discussion, let's assume that that's
what the user expects. We don't expect Subversion to remember that the
change is "permanently unwanted, and dealt with by rejecting it"; that
would be a different issue.)

  * If we reverse-merge a change that *isn't* recorded in the target
branch's mergeinfo, then we silently proceed without recording anything.

Am I understanding this correctly? If so, then, we're thinking, that
inconsistency is where things start to go wrong when you next try to use
"automatic" merges between the branches.

I suppose this is a known limitation. The book says you can undo an old
change by reverse-merging it, and it is briefly mentioned under the name
"rollback merge" in
<http://svn.apache.org/repos/asf/subversion/trunk/notes/merge-tracking/requirements.html#rollback-merge> and <http://svn.apache.org/repos/asf/subversion/trunk/notes/merge-tracking/func-spec.html#repeated-merge>, but it seems in practice that although you can perform a reverse-merge once it is not consistently tracked thereafter. I don't know if we have anywhere a user-facing description of what merge scenarios are really supported by merge tracking.

What Philip and I were thinking is that we can improve the support for
reverse merges by always recording a reverse merge when it happens. At
the moment, all changes in a branch's own line of history are implicitly
part of its mergeinfo, they are not stored explicitly, and therefore
there is no way to record that one of those changes is now missing. But
if we stored the branch's own history explicitly then a reverse-merge
from its own-history could be recorded in just the same way as a
reverse-merge from any other branch.

Of course that's hand-wavey as regards implementation details, but does
that sound sane in broad terms? For a start, the assumption that this
is a known deficiency?

- Julian
Received on 2011-08-30 18:31:20 CEST

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.