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

Re: Symmetric Merge -- switched subtrees [was: no local mods or switched subtrees by default]

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Fri, 20 Apr 2012 10:36:32 +0100 (BST)

Paul Burba wrote on 27 March 2012:
> Julian Foad wrote:
>> The check for switched subtrees:  I think we should enable this by default.
>>
>> I suppose the issue here must be that we don't have a compelling use
>> case for supporting such a merge, and so we haven't defined and don't
>> want to spend the effort of trying to define what such a merge should
>> mean.  We can explain what the merge code *does* in such a case, we
>> just can't give a requirements-based reason for *why* it does what it
>> does.  Paul or anyone, please enlighten me if that's not the case.
>
> There are two "whys" to consider here:
>
> First, "why" does a user merge into a WC with switched subtrees?  On
> that I agree with you, I've never seen a compelling case is.  The few
> users I've come across who did it usually did so by mistake or were
> merging changes that they knew would not touch the switched subtree.

OK; nor me.  (I can see it could sometimes be convenient to merge into a WC with switched subtrees when the user knows that the merge will not touch the switched subtrees, but even so, that doesn't necessarily mean it's a good idea.)

> Regardless of why users do it, they do it and it was something we
> allowed merge to do pre-1.5 (i.e. pre-mergetracking), so I tried to
> support it.
>
> Second: Why does the merge code do what it does when faced with a
> switched subtree.  I'm guessing you see this "what" the code does,
> but
> that makes it sound as if the current behavior is somehow arbitrary.

Sorry, I did indeed imply it may be a bit unfounded, as I felt I had no point of reference for the "why".  But I agree it makes sense to behave as you described below...

> The "why" of the current behavior is tied to the fact that by default
> svn:mergeinfo is inheritable.  [...]:
>
>   WC-Root('/SRC:N')
>       |
>     SSP('/SRC:N*')
>       | \
>       |  \
>       |  SSS('/SRC:N')
>       |
>     SS('/SRC:N')
>
> a) Non-inheritable mergeinfo is recorded on the parent [...]
>
> b) Normal inheritable mergeinfo is recorded on the root [...]
>
> c) Normal inheritable mergeinfo is recorded on siblings [...]
>
> d) If the WC-Root isn't the parent [it gets normal mergeinfo ...]
[...]
> [1] There are other reasons a subtree might be missing [...]
> mergetracking behavior and reasoning for this behavior is the same in
> all these cases, though a bit simpler in the non-switched cases
> because the subtree is really missing and not "replaced" by something
> else.

This description would make a superior replacement for the
 first two bullet points of
<http://svn.apache.org/repos/asf/subversion/trunk/notes/merge-tracking/func-spec.html#switched-paths>,
 would it not?

There is an implied logic for the question "Why behave like this?" that seems pretty intuitive; let's see if I can actually capture it in words:

[[[
  If a subtree (SS) is switched, that means the user has chosen for
  the time being to work with a substitute for the original subtree
  (SS_at_BASE), knowing that any modifications made in SS can be
  committed only to the repository location of SS and the original
  subtree SS_at_BASE remains hidden and unaffected.

  The general semantics of a merge is to apply local modifications
  to the working copy and record the merge as having been applied
  to the tree that is represented by the working copy.

  Merge tracking should ensure that the subtree of the merge that
  goes into SS is recorded as being applied to SS, while the
  subtree SS_at_BASE should be recorded as not having received that
  merge.

  Since the working copy represents parts of two different branches,
  two parts of the merge are thus applied to the two different
  branches, and recorded as such when the user commits the result.

  If the user is doing a merge that may affect SS, it is reasonable
  to assume that SS is an alternative variant of SS_at_BASE rather than
  some totally unrelated item.  So, in terms of Subversion's loose
  branching semantics, SS is a 'branch' of SS_at_BASE.  If the user
  chooses to merge when the assumption is false and SS doesn't have
  a sensible branching relationship with SS_at_BASE, the result will be
  nonsensical or, in concrete terms, there will be merge conflicts.

  Note:  Many typical branching policies would forbid committing to
  two branches at once, let alone committing merges to two branches
  at once.  However, the user may have reasons for doing this merge
  without intending to commit the result as-is.
]]]

Your description cover cases where the merge may or may not affect the inside of the subtree.  One case not made explicit is where the merge deletes the switched subtree.  Would the rule there be:

   * If the incoming change deletes the path SS, then it is interpreted as deleting the entry SS from SSP's list of children.  Therefore SS is removed from the WC, and so is no longer a switched path, and the mergeinfo change can be recorded normally on SSP without any need for non-inheritable or subtree mergeinfo.  And as for the repository path that SS represented while it was still switched, we do not want to record any mergeinfo change on that path at all (nor on that path's repository-parent path, nor anything to do with it).

?

- Julian
Received on 2012-04-20 11:51:46 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.