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.

On Fri, Jan 29, 2010 at 09:36, Philip Martin <philip.martin_at_wandisco.com> wrote:
> "Bert Huijben" <bert_at_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
Received on 2010-02-17 20:02:12 CET