On Wed, Mar 31, 2010 at 05:19, Philip Martin <philip.martin_at_wandisco.com> wrote:
> Greg Stein <gstein_at_gmail.com> writes:
>...
>> 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.
Yes. That isn't intentional, but is a current artifact of the implementation.
>...
>>> 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.
After pondering... yup. I'd agree.
And note that deletes are similar -- the children do not need to be
reported/acted-upon separately from the parent operation.
>...
It is also near time for us to pick a solution here. I just had to
mark several tests as XFail() specifically because we cannot represent
an "add" within a copied subtree.
I would prefer a presence marker over "tricky interpretation" of the
copyfrom_* fields.
I believe that we have the following operations:
add: plain old add
add-within-copy/move: add within a subtree
replace: delete-base + add
replace-within-copy/move: delete-child + add
delete-base: deleting a base node
delete-child: deleting a child of an add/copy/move
copy(-within): same as add•
moved-here(-within): same as add*
moved-away(-within): same as delete*
I think the last three are the same as other stuff (meaning: no
consideration needed), but with some extra markers.
I'm thinking that we add the following presence values (for
WORKING_NODE.presence):
"added": same as "normal" today. clarifies what this really means. we
map this to status_added, so why not use this for the presence
anyways? no need to "minimize/conserve" the set of presence values.
"replaced": indicates an added/copied-here/moved-here node that
replaces a child of a copied-here/moved-here subtree.
"deleted": same as "not-present" today. clarifies what this really means.
"inherit": applied to children of copied-here/moved-here and
deleted/base-deleted nodes. implies that no commit operations are
required for these nodes.
The APIs from wc_db should remain the same. This is a database-only
change. The concepts are surfaced through read_info(),
scan_addition(), and scan_deletion() as before.
Thoughts welcome. There is no particular rush on this, but I'd hope to
complete it in the next few weeks. This change will require a format
bump, which I would perform *before* the props-in-database change
(which still has db-state inconsistency problems to work through).
Cheers,
-g
Received on 2010-04-07 05:51:11 CEST