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

Re: Merge policies

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Fri, 20 Apr 2012 11:17:04 +0100 (BST)

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 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.

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 12:17: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.