Julian Foad <[email protected]> writes:
> A
> A/F
> A/G
> A/H
> X
> X/G
> X/H
> X/I
>
> and then (in Subversion) I replace A with a copy of X:
>
> rm A
> cp X A
>
> and then delete the child 'H' and add a new child 'J':
>
> rm A/G
> mkdir A/J
>
> I expect to the "working view" of A to consist of
>
> A - copied, replacing an old 'A'
> A/G - scheduled for delete (was a copied child of 'A')
> A/H - copied (as a child of 'A')
> A/I - copied (as a child of 'A')
> A/J - scheduled for add
You haven't got all the cases there. If A included A/L originally then
you could mkdir A/L after the copy. Then
A/L - scheduled for add (original A/L deleted as a child of A)
>From a wcng view A/L is added, not replaced.
> Note that I don't expect to hear anything about the path 'A/F'.
> Currently, 'F' is included in the results returned by
> svn_wc__db_read_children() and svn_wc__db_read_children_info().
>
> On the right track?
It sounds plausible, although whether there are things that rely on the
old behaviour I don't know.
--
Philip
