> -----Original Message-----
> From: MARTIN PHILIP [mailto:codematters_at_ntlworld.com] On Behalf Of
> Philip Martin
> Sent: vrijdag 18 januari 2013 16:50
> 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'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?
You won't be able to commit these with either editor v1 or v2.
The node was not added before, so it has no history to move.. If it had
history it is just copied to a different location
>
> > (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.
But for update handling the move handling is useless to users of IDEs if it
doesn't allow you to remove a directory, while moving all nodes inside to
different other directories.
This is not one move: it is a move of all those files, and a plain delete of
that directory.
Only tracking that top directory as move is not implementing true renames in
my world. Not even close.
(See reply to stsp for the use case... Not with the worst case all 'A'
names, but we shouldn't break on those either)
I would have to spend more time working on an example, but it is possible to
have one path (at different op-depths) moved to several places, by replacing
an ancestor, moving at the path... replacing a nearer ancestor and then
moving at the same path... That can happen for any number of versions <
op-depth(path).
We need to support all of that in order not to break the database.
[Not sure if any of this makes sense in the status output... But the
database should store it correctly]
WC-NG was designed to never break down on whatever operation you throw at
it, and I think we should keep the move code to the same standard.
(Of course there will always be bugs, but we shouldn't design things where
we must lose data)
We designed WC-NG to keep track of the 'presence' of nodes, not to keep
track of what way you got to a certain state. The move implementation
appears in some ways to have gone a different direction. Keeping track of
how things changed may require a completely different design as things might
be partially undone, etc.
Bert
>
> --
> Certified & Supported Apache Subversion Downloads:
> http://www.wandisco.com/subversion/download
Received on 2013-01-18 17:40:02 CET