On Wed, Apr 7, 2010 at 05:44, Philip Martin <philip.mar...@wandisco.com> wrote: > Greg Stein <gst...@gmail.com> 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.
Ignoring my "convert not-present to excluded" concept... I think excluding a node is just cleaning up your working copy, but those nodes participate in any ancestor operation (delete, move, copy). Note that we don't have a copy-with-depth operation at the moment, but I think we could do so in the future. e.g copy immediates, with sets child dirs to depth=empty. or copy files which sets child dirs to excluded. In these cases, the children are still "there", but just not in the working copy. Cheers, -g
