subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bert Huijben" <b...@qqmail.nl>
Subject RE: holes in the WC-NG schema?
Date Fri, 05 Mar 2010 16:43:45 GMT


> -----Original Message-----
> From: Neels J Hofmeyr [mailto:neels@elego.de]
> Sent: vrijdag 5 maart 2010 11:45
> To: dev@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)

We need a more advanced schema to fix this category. The simple fix would
fix this behavior we supported in 1.6, but we might want the better fix.

	Bert



Mime
View raw message