> -----Original Message-----
> From: MARTIN PHILIP [mailto:codematters_at_ntlworld.com] On Behalf Of
> Philip Martin
> Sent: maandag 12 november 2012 16:22
> To: Bert Huijben
> Cc: dev_at_subversion.apache.org
> Subject: Re: move updating and mixed revisions
>
> Bert Huijben <bert_at_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.
Yes or no.
We just complete the update, installing the move tree-conflict on the move
source. After the update (and the bump), BASE at the move-source now has a
single revision.
The move-target is unchanged at this point. Then we start move-resolving
(still as part of the same 'svn update' invocation, but not before bumping):
The move-target is then still as it was, when it was originally moved (or
really copied), a mixed revision tree that has different layers when it was
mixed revision and/or switched.
As part of the resolving we want to collapse the mixed revisionness of the
move-dest tree to a single revision.
>
> 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.
B/f doesn't exist in the repository, so how would you record a move history?
We can only record moves from BASE to another location in a commit.
I would say B/g is not a move of B/f, but a move of A/f.
This is how we would record it in history/the repository if we commit it.
And in that case the necessary storage location is available.
(The only way to record it in a different way would be to use two commits. I
would suggest that in that case the commit logic should rearrange things for
the new move-from location or the database would be inconsistent)
I think you are making things very hard by looking as moves of added nodes
in the same way as moves of committed nodes. We never did this when
designing the WC-NG storage.
Getting moves of additions to work, requires designing offline commit
handling.
(Which essentially requires adding another op-depth dimension and the logic
to handle all that)
Bert
Received on 2012-11-12 16:49:12 CET