On Wed, Apr 7, 2010 at 05:44, Philip Martin <philip.martin_at_wandisco.com> wrote:
> Greg Stein <gstein_at_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
Received on 2010-04-07 21:56:01 CEST