[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Bert Huijben <bert_at_vmoo.com>
Date: Thu, 18 Feb 2010 00:03:40 +0100

> -----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.

> 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
> 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

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
(Spurious deletes, ..., ...)

The result is that we will have to think about this.


> (and thanks for finding this hole!!)
> Cheers,
> -g
Received on 2010-02-18 00:04:18 CET

This is an archived mail posted to the Subversion Dev mailing list.