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.
Hi Julian,
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:
http://subversion.tigris.org/issues/show_bug.cgi?id=2881
> 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