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.mar...@wandisco.com> wrote: Greg Stein <gst...@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
