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

Re: Move Tracking in the Update Editor

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Wed, 4 Sep 2013 12:14:26 +0100 (BST)

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

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.