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