Am 24.04.2012 16:32, schrieb Julian Foad:
> 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 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.
Observation on my part: I think it is ironic that a
centralized VCS tries to do de-centralized merges
with all the missing information and special cases
that it has to allow for on the client side. Those
special cases stem from features that you need to
have (sparse wc, mixed revs) as long as you want
to have client-side WCs.
Maybe, the "right way" to do merges would be
server-side merges. But I'm not advocating to put
any effort into that right away ;)
>
> 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.)
For experience with large working copies, I would not
want SVN to ask me to update to HEAD whenever I
happen to fall behind. It is a nuisance already that I
often have to update before I can commit the merge
because SVN would not allow to modify the directory
properties (svn:merge-info) without the directory
content being up-to-date.
The issue with large working copies is clearly the time
factor: Non-merging users can commit quickly, i.e. often.
A merging user needs to update the whole WC and then
try to commit.
>> * 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.
OK.
>> 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.
Same feeling here. SvnDay @Berlin would be an excellent opportunity
to discuss some these more fundamental questions.
As I'm writing this, I'm on my way to Antalya where I can discuss
with Cristian and Andy directly which concrete improvements
can be made right now. For the time being, I would like to focus
on the rename tracking part and support testing efforts. I would
expect that to minimize the coordination overhead.
-- Stefan^2.
Received on 2012-04-29 20:23:05 CEST