Julian Foad <julianfoad_at_btopenworld.com> writes:
> 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.
There is a related issue with mixed-revision working copies. Suppose A
gets moved to B in some commit. A mixed-revision working copy could
contain both A and B so what does the update that includes that commit
do? I suppose the server still sends some sort of "move A B" operation
but we may want the server to tell the client that B is not being
replaced.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Received on 2013-09-04 20:58:47 CEST