Greg Stein <gstein_at_gmail.com> writes:
> I believe that we have the following operations:
>
> add: plain old add
> add-within-copy/move: add within a subtree
Those two are much the same. It makes little difference whether it's
a plain add, an add within an add or an add within a copy/move.
> replace: delete-base + add
> replace-within-copy/move: delete-child + add
There is also
replace: base node not-present + add
the old deleted=true state. This is explicitly excluded from being a
replace in svn_wc__internal_is_replaced but that may be a bug (it
causes revert to erroneously remove the not-present base node).
> 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'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.
Being able to distinguish add and replace is not enough for full 1.6
compatibility. When a node replaces a copied child it overwrites the
child's data, things like checksum and properties. This data is not
derived or inherited from the copied parent, so it cannot be restored
after being overwriten. In 1.6 it is possible to revert the replace
and restore to the copied child.
Another problem is a copy of a mixed revision tree that includes base
nodes that are not-present. In 1.6 we represent these as "fake"
schedule deletes in the copy, so that they are explicitly deleted when
the copy is committed. This works but has problems, the main one
being that if one tries to revert the delete the full node information
is not available (because the not-present source doesn't have it).
Perhaps we should have a distinct presence for this type of node?
There are similar questions about absent and excluded nodes.
--
Philip
Received on 2010-04-07 10:53:25 CEST