Bert Huijben <b...@qqmail.nl> writes:
> A few weeks ago I proposed updating the database to exactly that move with
> replacements on the first update step. This adds the nodes that were not
> added by the initial move (aka the copy) in the op-depth of the move. From
> that point the normal status api will exactly report the replacements that
> will happen when committing. (Before adding those nodes the replacements
> would also happen, but you would only see them after the commit)
>
> After that initial step we can help the users who got themselves in this
> situation (by moving from a mixed revision working copy) by trying to
> remove as much of those replacements as possible.
>
> In many cases it will only be the revision number that has changed. But in
> these cases we have two NODES layers on top of each other with the same
> repos_id and repos_relpath where the top one has a moved-from set.
>
> We can then -as part of the same sql transaction, or as a different
> sql transaction- try to eliminate layers as part of the conflict resolving.
> This might involve text and property merges and in some cases installing
> new conflicts. We can than remove the shadowing.
I think what you are describing some variation of the following. We
start with a single-revision, single-op-depth move. During the update
the base nodes in the move source become mixed-revision and the working
nodes in the move destination are updated so that they become
multiple-op-depth and mixed-revision. Then as the update continues and
the move source moves back to single-revision we collapse the
multiple-op-depth move back to a single-revision move.
That is how I originally imagined move updating would work. The problem
is that it can't handle user modifications after the move. Things like
nested moves, adds, copies all obstruct the extra op-depths we would use
for the mixed-revision move destination:
svn mv A B
op-depth local-relpath presence revision moved-to moved-here
0 normal 3
0 A normal 3
0 A/f normal 3
1 A deleted B
1 A/f deleted
1 B normal 3 1
1 B/f normal 3 1
This could be update node-by-node with B and B/f becoming mixed-revision
and multiple-op-depth for a period before becoming single-revision
again. However with a nested move:
svn mv B/f B/g
op-depth local-relpath presence revision moved-to moved-here
0 normal 3
0 A normal 3
0 A/f normal 3
1 A deleted B
1 A/f deleted
1 B normal 3 1
1 B/f normal 3 1
2 B/f deleted B/f
2 B/g deleted 1
Now when I update A and pass through a mixed-revision I can't use
op-depth=2 to represent the mixed-rev move in B because those rows are
already being used. Supporting updating nested moves has to happen or
this whole feature is pointless.
The only way I can see to update moves is to restrict our handling of
moves to single-revision destination. We move from one single-revision
state to another. So we start with a single-revision move from A to B.
The user runs update which makes A mixed-revision and "breaks" the move.
At the end of the update A is single-revision again but a different
revision from B and the move is still "broken". The user runs some sort
of resolution and B is updated to match the revision of A and so the
move is no longer broken. If the update is interrupted part way through
so that A remains mixed-revision then the user cannot resolve the broken
move until A is updated to single revision. The "broken" move acts much
like a tree-conflict, the user cannot commit until it is resolved.
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
