Re: svn commit: r1434913 - /subversion/trunk/subversion/libsvn_wc/wc_db.c

"Bert Huijben" <bert_at_qqmail.nl> writes:

> I'm still not sure if the current scheme scales under the move of multiple
> subtrees
>
> svn mv A Z
> svn mv Z/B B
> svn mv Z/C C
> svn rm Z

The "svn rm Z" is removing half of a move (A-to-Z) so it currently
fails. If we allow the delete what happens to A? It can't be marked
moved-to Z because Z no longer exists.

> svn up
>
> So after this A/B is still moved to B and A/C to C, but keeping track of all
> of this will take a lot of work.

Go back to the start:

svn mv A/B B
svn mv A/C C
svn rm A

This results in A/B to B and A/C to C with A deleted:

D A
D A/B
> moved to B
D A/C
> moved to C
A + B
> moved from A/B
A + C
> moved from A/C

> I would guess it is much simpler to store in op_depth A/B that it is
> currently in B, and in op_depth A/C that it is in C. (and while doing the
> above that A was at Z)
>
> The status walker currently just checks what is stored in the latest read
> op-depth, so that code is certainly broken over multiple layered moves where
> subtrees are involved.

Perhaps it is. What goes wrong? The whole status API doesn't really
work very well with replace in general irrespective of move tracking.
Status only sees the top operation at any given path.

> svn mkdir --parents A/A/A/A/A/A
> svn ci -m ""
> svn mv A/A/A/A/A/A C
> svn mv A/A/A/A D
> svn mv A/A E
> svn mv B/A/ A/A
> and more things like this..

I guess B is a typo for D or E. I don't quite see what the problem
although there appears to be a bug in the implementation.

svn mv A/A/A/A/A/A C
svn mv A/A/A/A D
svn mv A/A E

ignoring the implementation bug we have:

A/A to E
E/A/A to D
D/A/A to C

then

svn mv D/A/ A/A

should give

A/A to E
E/A/A to D
D/A to A/A
A/A/A to C

> It is certainly possible to get multiple moved-froms at different depths the
> same path if you try a bit with a scheme like this.
>
> There is no way status or a single path can pinpoint a single moved-to this
> way, yet this is what the current apis offer.
>
> This problem will never occur with a storing moved-from in BASE (op-depth
> 0).

What about moves that don't involve a BASE node?

> (Moved-from is always stored in the op-root of the addition, so this can
> never have this problem... The problem is in the moved-to scheme)
>
> The current scheme appears to be designed to allow only tracking the root of
> deletes, which is just the easy case, compared to generic move tracking.

Yes, we are tracking move roots as those are the things that get
committed. There can only be one move root at any path/op-depth. There
can be moves inside moves and so there can be multiple moves at any
path/op-depth.

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download