On Fri, Aug 30, 2013 at 2:02 PM, Julian Foad <julianf...@btopenworld.com>wrote:
> Branko Čibej wrote: > > > On 30.08.2013 13:03, Julian Foad wrote: > >> I'm working on how the update editor can handle moves. It's more > >> complex than the commit editor, because there can be multiple > >> instances of the "same" repository node in the WC, so moves are not > >> necessarily unique. > >> > >> This is a copy of my notes in progress. I could use some suggestions > >> or thoughts if you have any? > > > > Here's a suggestion, please put this in the Wiki, not HTML (shudder) > > mail. :) > > Good suggestion. Done. > > <https://wiki.apache.org/subversion/MoveDev/MoveTrackingUpdateEditor>. > > Hi Julian, 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 ;) -- Stefan^2. 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. 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. 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.
