neels <neeels_at_gmail.com> writes:
> On 23 March 2010 09:11, Greg Stein <gstein_at_gmail.com> wrote:
>> On Mon, Mar 22, 2010 at 17:59, Philip Martin <philip.martin_at_wandisco.com> wrote:
>>> $ svn cp $url/A wc
>>> $ svn add wc/A/Y
>>>
>>> Suppose $url/A contains $url/A/X. How do I distinguish between a
>>> copied child, like wc/A/X, and an added node like wc/A/Y? Neither has
>>> copyfrom set. How do I know that A/X inherits from it's parent A
>>> while A/Y does not?
>>
>> Yes, you brought up this hole in the design a while back, and we've
>> had some discussion on ways to solve it.
As I recall the last problem was a copied child that was first deleted
and then replaced, and the problem is that there is only one working
node to represent both the deleted and added nodes.
This problem is vaguely similar but here we have two working nodes, so
we have enough storage is just a matter of deciding which values to
store.
>> As Bert points out, you can
>> use changed_* to detect the local-add, rather than local-copies.
>>
>> We may introduce a special copyfrom_* value to indicate "local-add"
>> rather than "copy-from". Or maybe rely on changed_*. It is unclear on
>> what is the best approach right now.
We should consider using copyfrom_repos_path. The current method of
only storing copyfrom_* on the root of the copy means that
copyfrom_repos_path needs to be calculated every time its value is
required. The other copyfrom_* fields contain the same value through
the copy, so it makes sense to elide those where possible. We could
use something like:
copyfrom_repos_id == NULL copyfrom_repos_path == NULL : added, no copy
copyfrom_repos_id != NULL copyfrom_repos_path != NULL : root of copy/move
copyfrom_repos_id == NULL copyfrom_repos_path != NULL : child of copy/move
> May I suggest to use the WORKING node's 'presence', as we already do
> with subpath deletions inside copied trees. A presence of
> 'not-present' currently indicates that a subpath of a recursive copy
> is excluded from the copy, IOW that it is the root of a delete
> operation inside a copy. A new value called 'not-related' could
> indicate that a path is the root of an *add* operation that is not
> related to the add operation of its parent.
I suppose we could, but I think we already have enough storage for
this problem. If we were to adopt a new presence I think I'd make the
copied child have the new value. Nodes that are simple adds are very
similar to nodes that are the root of a copy: both represent new items
in the repository and it seems reasonable that they have the same
presence value. Copied children are the ones that are special or
different.
--
Philip
Received on 2010-03-24 21:41:55 CET