> -----Original Message-----
> From: Greg Stein [mailto:gstein_at_gmail.com]
> Sent: donderdag 18 februari 2010 0:19
> To: Bert Huijben
> Cc: Philip Martin; dev_at_subversion.apache.org
> Subject: Re: '@BASE keyword' vs. 'BASE database-tree' vs 'BASE conceptual-
> tree'
>
> 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.
No, you need N overlays.
Take a repository containing a path
^/A/A/A
and copy that path as
svn cp ^/A/A/A/A/A/A/A A
svn cp --force ^/A/A/A/A A/A
svn cp --force ^/A/A/A/A A/A/A
svn cp --force ^/A/A/A/A A/A/A/A
(etc.)
If you want to be able to replace at all those levels and fully revert to
the undeleted state you need more than one extra tree.
Bert Huijben
>
> Thus, I leave a problem to the readers, for now. I'll regroup on this
> tomorrow.
>
> Cheers,
> -g
Received on 2010-02-18 08:41:36 CET