Delete and revert both modify WORKING_NODE while leaving BASE_NODE (if it exists) unchanged. The two operations can modify or delete the WORKING_NODE associated with a BASE_NODE. Delete can also create a new WORKING_NODE. The original state before the operation can be characterised by BASE_NODE.presence and WORKING_NODE.presence, and only WORKING_NODE.presence changes (except when a new WORKING_NODE is created). There are 5 possible BASE_NODE.presence values: normal, incomplete, absent, excluded, not-present in addition to when the BASE_NODE does not exist. There are 6 possible WORKING_NODE.presence values: normal, incomplete, absent, excluded, not-present, base-deleted in addition to when the WORKING_NODE does not exist. ### A comment in 'wc-metadata.sql' says not all of 6 values are allowed in WORKING, but it may be wrong. A wc-to-wc copy could have absent and excluded presence values in the BASE source, does the copy put those values into the working tree? A url-to-wc copy could get an authz failure part way through, does that result in an absent node? There is currently no UI to do a sparse url-to-wc copy, but if there was then would that result in an excluded node? When removing a WORKING_NODE any ACTUAL_NODE is also removed. ------original-state------- ----delete---- BASE_NODE WORKING_NODE WORKING_NODE - normal or not-present [1] incomplete or - [2] absent - excluded - [3] not-present - base-deleted - normal base-deleted normal normal base-deleted or not-present [4] normal incomplete base-deleted or - [5] normal absent - normal excluded - [3] normal not-present - normal base-deleted - incomplete base-deleted incomplete normal base-deleted or not-present [4] incomplete incomplete base-deleted or - [5] incomplete absent - incomplete excluded - [3] incomplete not-present - incomplete base-deleted - absent - absent normal x absent incomplete x absent absent x absent excluded x absent not-present x absent base-deleted x excluded base-deleted excluded normal base-deleted or not-present [4] excluded incomplete base-deleted or - [5] excluded absent - excluded excluded - [3] excluded not-present - excluded base-deleted - not-present - not-present normal or not-present [1] not-present incomplete or - [2] not-present absent - not-present excluded - [3] not-present not-present - not-present base-deleted - ------original-state------- ---revert--- BASE_NODE WORKING_NODE WORKING_NODE - normal or - [6] incomplete or - [6] absent - excluded - not-present normal base-deleted normal - normal normal or - [6] normal incomplete or - [6] normal absent - normal excluded - normal not-present normal normal base-deleted incomplete - incomplete normal or - [6] incomplete incomplete or - [6] incomplete absent - incomplete excluded - incomplete not-present normal incomplete base-deleted absent - absent normal x absent incomplete x absent absent x absent excluded x absent not-present x absent base-deleted x excluded - excluded normal or - [6] excluded incomplete or - [6] excluded absent - excluded excluded - excluded not-present normal excluded base-deleted not-present - not-present normal or - [6] not-present incomplete or - [6] not-present absent - not-present excluded - not-present not-present normal not-present base-deleted key --- - : operation not allowed or no change required x : original state not allowed ### it would be nice to call out the operations that are "not allowed" notes ----- [1] if the root of the copy, not-present otherwise. [2] if the root of the copy, - otherwise [3] A sparse copy, should commit automatically delete an excluded node? [4] base-deleted if the root of the copy, not-present otherwise [5] base-deleted if the root of the copy, - otherwise [6] if the root of the copy, - otherwise Generally BASE_NODE.presence normal and incomplete are treated the same, since update can change one into the other at any time. It's not possible to delete something with WORKING_NODE.presence incomplete unless it's the root of the copy. If we transformed it to not-present revert would not be able to go back to incomplete. It's possible to delete something with BASE_NODE.presence excluded because the name alone is sufficient information at commit time. WORKING_NODE.presence excluded is more difficult. Should commit automatically delete an excluded node? There are arguments for and against. If commit doesn't automatically delete the node can the user delete it in the working tree? Like WORKING_NODE.presence incomplete the problem is that revert would not be able to cope. ### gstein sez: commit should NOT do a deletion for an excluded node. ### the presence is typically used for (say) copying a large tree, ### and then excluding the subtree within the copy from the working ### copy. maybe the user doesn't want all that stuff there. at ### commit time, the copy is performed, and nothing more. if you ### wanted to delete this node, then switch it to depth=empty ### and presence=not-present. Pre-centralisation directories can be obstructed, any such nodes can be treated as presence=normal.