Stefan Fuhrmann wrote: > On Fri, Aug 30, 2013 at 2:02 PM, Julian Foad wrote: >> <https://wiki.apache.org/subversion/MoveDev/MoveTrackingUpdateEditor>. > > I read the wiki page and agree that all those issues are real. > > So, here is my take on how to address them. Maybe you > find something useful in there ;)
Thanks, Stefan. > Multiple Move Targets > --------------------- > > This can only happen with switched paths in the working copy > as you need to have a given path@rev more than in one in your > working copy. > > Switched sub-trees are already "isolated" from changes in > other parts of the working copy in the sense that an update, > commit or - most importantly - modification in one part does > not modify any switched sub-tree that happens to mirror these > paths. > > If we modify a node in the working copy and that node gets moved > as part of the update, it is perfectly reasonable to say that > the local change will not be propagated to any switched sub-tree > but requires a commit and update cycle to show up there. Even > if the move was 1:1, it still should not cross switch boundaries > but appear as a deletion + potential tree conflict during update > and as an addition in the switched location. > > Finally, having switched sub-trees mirror other parts or the > working copy seems to be a non-standard usage of the 'switch' > feature originally designed to make it easy to switch between > various branches. We have to deal with it but we don't need > to get fancy here. I agree with you up to here. > My suggestion for how the update editor might work (see below) > allows for multiple copy targets. But for simplicity, the > client may decide to eliminate moves that cross switched > sub-tree boundaries. I'm afraid my gut feeling about your 3-stage suggestion is it's a horrible hack :-) But I don't quite understand it in detail. What I like about it is that the client gets the info about all moves that affect nodes in the WC, even those where it is only going to want to perform a delete or add (half a move) in the end. That's good because it allows the client to make decisions and/or inform the user about exactly how it wants to manage the WC. But I don't like it being two separate client-server communications which partly overlap in content (they both contain *some* info about moves, if I understand you). - Julian > Multiple Move Sources > --------------------- > > This might happen relatively frequently if people move nodes > over "long distances" in the tree and users update only parts > of their working copies. > > Again, the update editor should support multiple sources for > a given move but the client is free to narrow it down to one > (or even zero). > > For the first implementation, I suggest that the most recent > (revision-wise) of the move sources is being used and a simple > deletion is done to all other move sources. Chances are that > this simply works without being noticed by the user. If there > were local changes to the older instances of the moved node, > those will cause tree conflicts as they do today. > > > Update Editor / Reporter Drive > ------------------------------ > > I suggest a 3-stage process: > > (1) Client communicates the working copy path + URL@rev list > to the server and gets a list of all moves relevant to the > working copy from the server (being tagged with local path > info in a "baton-esque" manor, i.e. the server does not > need to understand them). This might be done in a process > similar to the actual update / reporter drive but will be > much faster as it only requires wc.db queries. > > (2) Client filters list to eliminate multiple sources as well > as cross-switch moves. It also knows the list of "move > from" paths now and can handle them transparently for any > incoming move or other modification. > > (3) Client passes the filtered list to the normal update editor / > reporter drive as today. If an ADD happens to match a move > target, the editor will send a MOVE instead and continue to > recurse accordingly.
