Re: '@BASE keyword' vs. 'BASE database-tree' vs 'BASE conceptual-tree'

[Greg Stein <gs...@gmail.com>]

Pulling out this old email. I kept it marked because I think it may
highlight a problem in the schema.

On Fri, Jan 29, 2010 at 09:36, Philip Martin <ph...@wandisco.com> wrote:
> "Bert Huijben" <be...@qqmail.nl> writes:
>
>> * svn cp/mv/add/rm
>> These commands look at the current version of the working copy
>> (Based on BASE overlayed with WORKING) and apply changes to
>> WORKING. (And update your working copy and ACTUAL with' relevant
>> changes')
>
> How about the scenario in the other thread.  I copy a directory
> containing files: the new items have WORKING nodes but no BASE nodes.
> That's what happens at present and it seems to be correct.

Correct.

> Now I delete one of the copied files; what should happen is that the
> WORKING node gets modified to have WORKING.presence=not-present and
> there is still no BASE node.  That's not quite what happens at present
> and it appears to be a bug.

That is the intent. As Bert said, if that isn't what is happening (is
there a BASE node? is WORKING not marked right?), then it is
definitely a bug. What is the cause? Dunno.

> What happens if I add something to replace the deleted file?  Does the
> WORKING node somehow record both the original copy and the new add?
> There doesn't seem to be enough information stored: how would it cope
> with the node kind changing for example?

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?

(and thanks for finding this hole!!)

Cheers,
-g

RE: '@BASE keyword' vs. 'BASE database-tree' vs 'BASE conceptual-tree'

[Bert Huijben <be...@qqmail.nl>]

> -----Original Message-----
> From: Greg Stein [mailto:gstein@gmail.com]
> Sent: donderdag 18 februari 2010 0:19
> To: Bert Huijben
> Cc: Philip Martin; dev@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 <be...@vmoo.com> wrote:
> >> -----Original Message-----
> >> From: Greg Stein [mailto:gstein@gmail.com]
> >> Sent: woensdag 17 februari 2010 20:02
> >> To: Philip Martin
> >> Cc: dev@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

Re: '@BASE keyword' vs. 'BASE database-tree' vs 'BASE conceptual-tree'

[Greg Stein <gs...@gmail.com>]

On Wed, Feb 17, 2010 at 18:03, Bert Huijben <be...@vmoo.com> wrote:
>> -----Original Message-----
>> From: Greg Stein [mailto:gstein@gmail.com]
>> Sent: woensdag 17 februari 2010 20:02
>> To: Philip Martin
>> Cc: dev@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

RE: '@BASE keyword' vs. 'BASE database-tree' vs 'BASE conceptual-tree'

[Bert Huijben <be...@vmoo.com>]

> -----Original Message-----
> From: Greg Stein [mailto:gstein@gmail.com]
> Sent: woensdag 17 februari 2010 20:02
> To: Philip Martin
> Cc: dev@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