> -----Original Message-----
> From: MARTIN PHILIP [mailto:codematters_at_ntlworld.com] On Behalf Of
> Philip Martin
> Sent: vrijdag 18 januari 2013 11:20
> To: Bert Huijben
> Cc: dev_at_subversion.apache.org
> Subject: Re: svn commit: r1434913 -
> /subversion/trunk/subversion/libsvn_wc/wc_db.c
>
> "Bert Huijben" <bert_at_qqmail.nl> writes:
>
> > I think
> > $ svn mv A B
> > $ svn mv B A
> >
> > Will now store moved_from and moved_to in the same record, at the
> > op-depth of A. (Or copy_tests.py move_file_back_and_forth wouldn't
> > show moved_from and moved_to on a single node using status using the
> > code snippet here)
> >
> > How will this store a future move
> > $ svn mv A C
>
> I think:
>
> svn mv A B
> svn mv B A
>
> is shorthand for:
>
> svn mv A X
> svn mv B A
> svn mv X B
>
> If so then a subsequent:
>
> svn mv A C
>
> should result in A->B and B->C but it appears there is a bug in the
> implementation. The result is B->C but the A->B move gets lost.
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
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.
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.
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..
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).
(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.
Bert
Received on 2013-01-18 15:19:03 CET