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

Re: wc-ng base/working nodes in a copied tree

From: Greg Stein <gstein_at_gmail.com>
Date: Tue, 30 Mar 2010 19:07:02 -0400

On Wed, Mar 24, 2010 at 16:41, Philip Martin <philip.martin_at_wandisco.com> wrote:
> 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.

Okay.

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

I doubt that we use it independently of the other fields, so scanning
upwards for the others can also compute the relpath.

We do the same thing for the regular repos_id and repos_relpath.

> 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

Not sure about this.

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

Children of copies/moves/adds are all about the same. I think it is
the root that stands out, especially because it is *that* node where
we store the copy/move information. Thus, I would suggest a presence
named "root" or "oproot" (operation root).

This will solve the "add into another operation's tree", but it does
not solve the "did I replace a node in that tree? thus, do I need to
issue a DELETE before issuing this new operation?"

Having a "root" presence also means we can easily scan upwards for the
base of an operation. Hmm. Tho I guess the base of a deletion wouldn't
be marked root...

Anyways. Any thoughts?

Cheers,
-g
Received on 2010-03-31 01:07:29 CEST

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