On Thu, Sep 23, 2010 at 13:32, Julian Foad <julian.foad_at_wandisco.com> wrote:
>...
>> > 'excluded':
>> >
>> > I think we need to support 'excluded' at op_depth > 0 on a copied-here
>> > node (only for a child, not the root of the copy), and also on a
>> > moved-here node (child). We should distinguish these. How?
>>
>> "should"? Why? Again, looking at the parent immediately tells us what
>> is going on. But I don't even see where/how/why we need to know this
>> information.
>
> Maybe we'll never need to know, in practice. But I'm thinking from a
> "clean design" rather than a "how frequently are we likely to ask" point
> of view. For sanity there should be one way of asking questions such as
> "is this part of a copy", not two ways.
I don't know that that question is ever asked of an excluded node, is it?
I agree with minimizing exceptions, in general, but I'm not sure that
having multiple 'exception' presence values is useful. Especially when
a simple query on the parent provides the discriminator.
>...
>> At the moment, we do not record the local_relpath of the source of a
>> copy/move. (it may be null for a repo->WC copy; I believe we would not
>> allow a repo->WC move)
>
> Hmm. If the 'moved-*' presence values are indeed intended to support
> atomic moves (in the future), we may need to re-think how they are to do
> so. Storing the local_relpath (and op_depth I guess!) of the source is
> probably going to be a necessary part of the puzzle.
>...
>> > One of the particular desired behaviours of a move is that 'update' will
>> > still update it.
>>
>> So you say. I don't know that that is true.
>>
>> After a WC-WC copy, we don't update the copied nodes (afaik), so I
>> don't see that this immediately follows.
>
> We should discuss support for 'moves' separately.
Yeah. I didn't want to get too deep-ended on move semantics.
Representation within the database? Sure. But I'm also fine with
getting a first-order approximation and deferring until 1.8 (or
whenever we push moves down into the database).
>...
>> > Except for reverting, where you can get the reverse of your last point.
>> > For example, follow your last step "3." with "4. revert B. delete row
>> > <A/B, 2>. modify rows <A/B/C, 2>, <A/B/gamma, 2>: op_depth = 3.
>>
>> No. Step 3 subsumed the delete from step 2. All knowledge of it is
>> lost. A revert will delete the three rows at op_depth=2 and expose the
>> original checked-out rows.
>
> I meant a non-recursive revert, which just reverts 'A/B', and leaves its
> children deleted. That's when it has to re-write the children as if
> they had been deleted individually.
Oh! I hadn't thought of a non-recursive revert. You're quite right in that case!
Thanks,
-g
Received on 2010-09-23 19:41:37 CEST