Julian Foad <julianf...@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*
