On Tue, Aug 30, 2011 at 12:30 PM, Julian Foad <julian.foad_at_wandisco.com> wrote:
> 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.
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?
> I suppose this is a known limitation.
Yes, it is a know problem, a very old one at that:
> 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?
Received on 2011-08-30 18:46:11 CEST