> -----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.
Bert
>
> (and thanks for finding this hole!!)
>
> Cheers,
> -g
Received on 2010-02-18 00:04:18 CET