on phone, so this will be terse, but wanted you to consider: I'd thought
about the copy-of-not-present case, and think we should actually represent
those nodes as excluded.
Thoughts?
On Apr 7, 2010 4:52 AM, "Philip Martin" <philip.martin_at_wandisco.com> wrote:
Greg Stein <gstein_at_gmail.com> writes:
> I believe that we have the following operations:
>
> add: plain old add
> add-within-copy/move: ad...
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(-wi...
> I'm thinking that we add the following presence values (for
> WORKING_NODE.presence):
>
> "added":...
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 11:24:07 CEST