On Wed, Feb 17, 2010 at 18:03, Bert Huijben <bert_at_vmoo.com> wrote:
>> -----Original Message-----
>> From: Greg Stein [mailto:gstein_at_gmail.com]
>> Sent: woensdag 17 februari 2010 20:02
>> To: Philip Martin
>> Cc: dev_at_subversion.apache.org
>> Subject: Re: '@BASE keyword' vs. 'BASE database-tree' vs 'BASE conceptual-
>> tree'
>>
>> Pulling out this old email. I kept it marked because I think it may
> highlight a
>> problem in the schema.
>>
>
> <snip>
>> Here is a problem.
>>
>> If this new child is moved/copied here, then we'll end up with that
>> information in copyfrom_*, and can distinguish the ancestor's move/copy
>> from this child's move/copy.
>>
>> But if you simply "add", then we have no way to determine that this add is
>> NOT the child implied by the ancestor's move/copy to this location. There
> is
>> no defined marker.
>>
>> Grr.
>>
>> Maybe we have a qualified value for copyfrom_repos_id that means "locally-
>> added" ? We could set this on the root of all local-adds.
>>
>> Thoughts?
>
> [Rephrased from IRC]
>
> I like the copyfrom_repos_id overloading to fix the local added issue..
> But I still see some related issues that we can't handle by this simple fix.
>
> * What happens if I delete such a local added node (over a copied with
> history node)?
> One solution would be to always converted these to WORKING_NODE state
> not-present?
>
> The original WC-NG ideas stored somewhere in our repository talked about
> solving this by storing some of the copy-from info in BASE_NODE, but I
> really don't like that idea. We really need BASE_NODE free to *always* allow
> updating from a repository even if the working copy contains something
> completely different.
>
> It is an issue with not being able to express everything in WORKING_NODE and
> we shouldn't solve that by abusing BASE_NODE.
>
> Gstein responded by noting that we need to record a local-replace in
> WORKING_NODE to handle this case.. But that might open up another can of
> worms.
> (Spurious deletes, ..., ...)
>
>
> The result is that we will have to think about this.
Part of the problem is trying to represent multiple operations within
just the two trees.
1) copy tree
2) delete subtree A
3) local-add node A
4) delete node A
Step (4) needs to put a not-present node at A. But compare this to:
1) copy tree
2) local-add node A
3) delete node A
Step (3) should just remove the local-add, leaving no trace.
How to differentiate?
We've been viewing WORKING as an "overlay" of operations on top of the
BASE tree. Conceivably, we could have N overlays. This would provide
ample history on what to do, and how to unwind.
That said, maybe the above sequence of (1..4) is as complicated as it
gets, and we just need "one more" overlay. I'd need to engage my brain
(which isn't right now), but there may be another iteration on the
above which demonstrates a need for "another" overlay. And if so, then
the Proper Solution moves to N overlays.
Thus, I leave a problem to the readers, for now. I'll regroup on this tomorrow.
Cheers,
-g
Received on 2010-02-18 00:19:36 CET