Re: Merge policies

On Fri, Apr 20, 2012 at 6:17 AM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> Paul Burba wrote:
>
>> On Thu, Apr 19, 2012 at 12:57 PM, Julian Foad wrote:
>>>  Branko Čibej wrote:
>>>>  By the way, I'm all for removing support for merging into
>>>> mixed-revision
>>>>  and/or switched-subtree working copies. There's too much room for
>>>>  unexpected results in these cases.
>>>
>>>  I don't necessarily disagree, but that sounds a bit unsubstantiated.
>>> Is there too much "room for unexpected results" because you don't  have
>>> a mental model of what to expect?  If I were to figure out and describe
>>> some sensible semantics and a use case, might you then change your mind?
>>>
>>>  FWIW, I have an inkling of how a mixed-rev target WC should work: it's
>>> logically very similar to having different mergeinfo on different subtrees,
>>> except that the differences are on the target side of the merge rather than
>>> the  source side of the merge.  It requires some care to be sure that the
>>> parent-to-child inheritance of mergeinfo in the WC remains valid where base
>>> revision numbers differ.
>>>
>>>  That said, I can't imagine any valid reason to need to support a
>>> mixed-rev target WC.
>>>
>>>  I have thought very little about about how switched subtrees should
>>> work [and use cases].
>>>
>>>  Maybe Paul can help fill in some of the "how" and "why" gaps here?
>>
>> I believe I answered this question already, see:
>> http://svn.haxx.se/dev/archive-2012-03/0632.shtml%c2  If that doesn't
>> sufficiently answer your questions let me know.
>
> Hi Paul.  Yes, what you wrote there makes sense as to how we handle switched subtrees and "why" in a logical sense.  I've just followed up with a reply to that email going into a bit more detail.

I replied on that thread.

> I feel that with this level of functional spec, Switched Subtrees is something I can now add to the Symmetric Merge design proposal.
>
> I see there's already a brief statement about sparse WCs too: <http://svn.apache.org/repos/asf/subversion/trunk/notes/merge-tracking/func-spec.html#sparse-checkouts>.  I'm not clear how the whole 'depth' thing works, though, if you add children to a directory that was initially sparse or exclude children from a directory that was initially depth non-empty.

Ah, welcome to my world! Yes, this is a tricky situation. If our
merge target is shallow (i.e. depth < infinity) and the merge applies
changes that would effect paths *deeper* than the immediate children
currently present, then those children are skipped and we set
non-inheritable mergeinfo to reflect that these changes were not
merged. Where it gets whacky is if the merge *adds* paths which are
immediate children of the children currently present (e.g. merge
target at depth empty, merge adds a immediate file to the merge
target). Today we add the file, despite the fact that the target's
depth is empty.

Before you claw your eyes out in frustration, read the issue I just
filed: http://subversion.tigris.org/issues/show_bug.cgi?id=4164 It
spells out the problem fairly clearly (I hope!).

Paul

> Do you have a pointer to some details about how a mixed-rev target WC is handled?
>
> I have now added a section "Mixed-Rev, Switched, or Sparse WC" to <http://wiki.apache.org/subversion/SymmetricMerge>.
>
>
>> As to removing support for merging into WCs with switched subtrees,
>> let's be clear that this *does* work today (if you think otherwise
>> please provide a use-case demonstrating what is broken).  Now maybe we
>> want to restrict these types of merges to make further improvements
>> possible (e.g. Julian's symmetric merge work), that I won't argue
>> against, but I want to be clear that we are making the choice to
>> remove some existing functionality as a trade-off in implementing new
>> functionality, rather than fixing a broken feature.
>
> Totally clear, yes, if that's what we decide to do.
>
> - Julian
Received on 2012-04-20 23:07:31 CEST