Re: holes in the WC-NG schema?

Bert Huijben wrote:
>
>> -----Original Message-----
>> From: Neels J Hofmeyr [mailto:neels_at_elego.de]
>> Sent: vrijdag 5 maart 2010 11:45
>> To: dev_at_subversion.apache.org
>> Subject: Re: holes in the WC-NG schema?
>>
>> Neels J Hofmeyr wrote:
>>> I remember someone talking of a hole. It went something like: If a
> folder is
>>> copied-here, all its children have locally added status, and I
> understand
>>> they refer to the op-root of the add to find out their history, i.e.
> that
>>> they are copied. Now what if I replace such a child node with a fresh,
> new
>>> node -- it will still think that it's part of the copy-here. Just vague
>>> memory, haven't verified. This one should be fixed if it turns out to be
> so.
>> Turns out we are aware of this problem. My noob shot at a solution would
> be
>> to have an indicator whether a WORKING node is the op-root of an add.
>> Then
>> we can have an op-root of an add within another op-root of an add without
>> confusion. We might indicate on the inner op-root that they are not the
> root
>> of all locally added nodes, but just the root of an add operation. (Or
> have
>> scan_addition() find out by also scanning the parent of each add-op-root,
>> which it does anyway when asked to find the repository path of the add,
>> which it derives from the op-root's parent's BASE tree node ('s
> ancestors).)
>
> This would fix local adds, but it is not a complete solution for allowing
> all revert scenarios from nested add with history trees. (especially the
> cases where you replace some subtree of an add with history with a different
> tree)

...are you talking about being able to revert layer-wise, like, only the
replace within, so that the originally copied tree is brought back? (I won't
 get too involved here on top of the other stuff, am just curious to know.)
I'm thinking, if it was allowed to contact the repos, revert could cope
using the current schema + op-root flag thing, I guess?

~Neels