Greg Stein <gstein_at_gmail.com> writes:
> 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:
>>
>> 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.
I see there is a comment to that effect in wc-metadata.sql so perhaps
that was the intent, but in practice repos_id and repos_relpath appear
to be set in every base_node.
>> 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'd disagree.
> 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).
Yes, roots stand out. But plain adds are like roots: they show up in
status, they need to be explicitly reported during a commit, they can
be reverted. Children of adds are themselves adds and are thus roots.
It's the children of copies/moves that are different, they are not
roots, their presence is implied by the presence of the parent.
> 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...
--
Philip
Received on 2010-03-31 11:20:28 CEST