[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: wc-ng base/working nodes in a copied tree

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Wed, 07 Apr 2010 09:52:43 +0100

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.

Received on 2010-04-07 10:53:25 CEST

This is an archived mail posted to the Subversion Dev mailing list.