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).
