On Fri, Mar 5, 2010 at 11:43, Bert Huijben <bert_at_qqmail.nl> 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)
I've thought on this, and I think the current schema, with the
addition the singular marker we talked about at the root of a (local)
add will be complete.
First, stop saying add-with-history. Those are copies or moves. Very
different from an add. We have three terms, each meaning something
different. Continuing to use the "with history" is simply confusing.
Now. The main thing here is that the local database records enough
information to construct a *commit* to the target repository. We do
not need to remember each and every operation that arrived at that
state. Only what is necessary to replicate the local state up to the
repository.
The WORKING_NODE tables models adds/copies/moves/deletes. The specific
columns in the schema, when not-null, define the roots of copies and
moves. These can be nested since each copy/move specifies a new root.
Deletes do not require this nesting of operations -- once you delete
an ancestor, then any prior deletes of descendants are irrelevant. Our
problem is that we do not model adds beyond "hey! there is a
WORKING_NODE!". Attaching a "fake" copyfrom_* can delimit these adds,
thus allowing complex nesting of what is present in the WORKING tree.
Thus, I state we *can* do a complete modeling, once we define a
singleton to mean "add".
> 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.
I disagree.
Cheers,
-g
Received on 2010-03-09 08:39:55 CET