On Fri, Aug 30, 2013 at 2:02 PM, Julian Foad <julianfoad_at_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_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.
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_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 14:55:10 CEST