Greg Stein <[email protected]> writes: > > 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. > > 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.
If the source has both excluded and not-present nodes, do we need to distinguish them in the copy? Would we delete all the excluded nodes in the copy when committing? There was a thread a few months ago where a user reported that a wc-to-repo copy of a sparse working copy didn't result in a sparse copy and asked if this was a bug; we didn't really reach a consensus about what would be the correct behaviour. -- Philip
