[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Move Tracking in the Update Editor

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Thu, 19 Sep 2013 14:39:51 +0100 (BST)

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_at_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_at_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.
Received on 2013-09-19 16:10:18 CEST

This is an archived mail posted to the Subversion Dev mailing list.