Philip Martin wrote: > 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. [...] > 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
Yes. That's this scenario: <https://wiki.apache.org/subversion/MoveDev/MoveTrackingUpdateEditor#One_Move.2C_One_Non-Move>. WC: (A@10, B@20); repo: (r10: mkdir A; r20: mv A B) Update to r20; A moves to B, and also the existing B is updated. and the steps would be: move away A; move to B (original A) delete B # move-away add B (copy-from ... A) # move-here: it conflicts > but we may want the server to tell the client that B is not being > replaced. That happens naturally. If B is being replaced by the moved A: WC: (A@10, B@10); repo: (r10: mkdir A B; r20: delete B; mv A B) Update to r20; A moves to B, replacing the previous B. then the server would include an additional "delete A" step: move away A; move to B (original A) delete B # move-away delete A add B (copy-from ... A) # move-here: it conflicts - Julian
