Re: [RFC] Children of a replaced node - schedule delete vs. deleted-by-the-replace

Julian Foad <julian.foad_at_wandisco.com> 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