[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Thu, 10 Mar 2011 19:14:20 +0000

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
Received on 2011-03-10 20:14:55 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.