Re: Merge policies -- sparse, mixed-rev and switched target WCs

Paul Burba wrote:

> On Fri, Apr 20, 2012 at 6:17 AM, Julian Foad wrote:
>> 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!  [...]
>   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%c2  It
> spells out the problem fairly clearly (I hope!).

The sparse-directories design <notes/sparse-directories.txt> doesn't seem to indicate the intended behaviour when update brings in a new child.  I've added a note about that to the end of that document.

It seems that the problem is not *how* to make merge behave the right way to be compatible with sparse directories, but that we haven't decided what the Right Way is.

Stefan Fuhrmann wrote:
> Am 19.04.2012 18:57, schrieb Julian Foad:
>> FWIW, I have an inkling of how a mixed-rev target WC should work [...]
>>
>> That said, I can't imagine any valid reason to need to support a
>> mixed-rev target WC.
>
> Well, in the end one will always commit against HEAD.
> But there are two use-cases of different importance
> that should be supported:
>
> * A WC is usually not at HEAD because commits don't
>   update unchanged nodes. On branches, the WC will
>   often contain the latest changes as few people work
>   on that branch. A WC of /trunk can be expected to be
>   outdated even if it was updated to HEAD shortly before
>   the merge.

Those are some valid observations.  Note that your third point doesn't result in a mixed-rev WC.  But it's not a big deal to ask the user to 'svn up' before merging, so it's not obvious that any of these situations mean we need to support merging into the WC without an update first.  (Of course I acknowledge that it would be *easier* for the user, if it doesn't cause other problems.)

> * Mixed-rev working copies are an intermediate step
>   in creating arbitrary configurations via 'svn cp WC URL'.
>   Merging into the copy target should be semantically
>   identical to merging into a mixed-rev WC.

Yes, I agree. 

>> I have thought very little about about how switched subtrees should work. 
>> However, I *can* imagine scenarios where the user has a large chunk of WC
>> switched, and now wants to merge something into the whole WC knowing that
>> it won't in fact touch the switched part.  That seems like a reasonable
>> thing to support: untouched paths being switched.  I haven't yet thought
>> of a use case for switched paths that are touched by the merge.
>
> We could even be more permissive: as long as the merge
> does not cross "switch boundaries" (switched / non-
> switched or switched to different URL) as may allow
> the merge.

Let's say A/B is switched relative to A.

You mean a merge where the specified target is A/B should succeed?  Yes,
 I agree with that, and that's already documented in
<http://svn.apache.org/repos/asf/subversion/trunk/notes/merge-tracking/func-spec.html#switched-paths>.

At first I thought you meant a merge where the specified target is A
could be allowed to succeed if it only touched paths inside A/B.  That
doesn't seem like a good idea.

> This could be a somewhat typical use-case for people
> using switched WCs. I would expect that these users
> want to merge into those sub-trees just like they
> would also 'svn up' them.

One thing is clear: this whole discussion is evidence that the way merging should work in a
 WC with sparse directories, mixed revisions and/or switched subtrees is not exactly clear.  I accept that we have existing behaviour as precedent for the common cases, as well as somne level of rationale; I'm not trying to say we have no idea at all.

- Julian
Received on 2012-04-24 16:33:32 CEST