Julian Foad wrote:
> Philip Martin wrote:
>> [...] I can imagine an enhanced Ev1 editor drive that does
>>
>> move away A
>> move to C (original A)
>> del A
>> move away B
>> move to C (original B)
>> del B
>> add C
>>
>> The deletes lead to tree-conflicts on A and B due to local mods. The
>> add creates a pristine C with no local mods. The user resolves the
>> tree-conflicts post-update and gets to choose which local mods are
>> merged to C, possibly both but one before the other, which may in turn
>> raise text/prop/tree-conflicts on C.
>
> This is good as far as local mods are concerned. The decision of how to combine
> A and B, or raise a conflict, is left to the WC client code as it should be, and
> sufficient information is provided about the nature of the changes.
>
> Functionally, this would work as you've shown. Regarding updating the base
> tree, however, note that the plain "add" in Ev1 is a node-by-node add
> of the whole subtree, which could be arbitrarily large. For performance, we
> must not use a plain add, as a move should be designed to execute in O(1)
> time. [...]
Philip pointed out to me that this would still be an improvement over what we have today. If we're going to get anything into a release cycle it must be broken down into manageable stages, so perhaps this is a good place to draw the line for a first stage.
I'm fairly well persuaded by this view.
- Julian
> It may be advantageous to come up with an implementation plan whereby
> move-awareness is introduced first to the repository side, with just enough
> support in the WC to make typical move scenarios work much better than they do
> today, and then as a second phase extend the WC to know about node-id
> relationships and complete the WC-side awareness (so that scenarios like the
> above commit-time failures are instead detected within the WC, and whatever else
> goes along with that).
Received on 2013-09-04 13:15:32 CEST