On Thu, Sep 23, 2010 at 13:32, Julian Foad <julian.f...@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
