A continuation of the previous conversation... ---------- Forwarded message ---------- From: Erik Huelsmann Date: 2010/7/5 Subject: Chat with Erik Huelsmann To: [email protected]
[...] Erik: ok: the presence state is one of the fields to be moved to NODE_DATA, right? 16:44 This means that nodes which are deleted in one of the hidden layers will retain that property. is that correct? 16:45 me: N_D will have its own presence field. still need that in B_N and W_N Erik: i see, only base deleted. ok. me: children of copy/move-here also need to be marked as deleted, 16:46 so that when you query for their data, you don't get a "stale" node Erik: because I was thinking that if the deleted-ness needs to be retained, shouldn't copied-ness be too? and if that should, don't we need copyfrom-* ? to be retained, that is me: copyfrom info only needs to be retained on the (operation) root of the copy, which is WORKING_NODE 16:47 Erik: ah. that's what Bert tried to tell me. me: mixed-rev working copies will have multiple op-roots, but that is where the data will be tho I like to call it original_* since it could be talking about a move-here 16:48 (the column names are before I started using the original_* names) (that is, working_node says copyfrom_*) Erik: so, if you delete part of a copied tree, to replace it with other stuff, reverting that will not bring back any copied state within that deleted tree. That's the conclusion. 16:49 (after all, you deleted a wc mod) me: if you copy a tree to A/newB, then you get NODE_DATA at op_depth=2 (iirc, on that nmber), and then if you delete A/newB/C, then you get a set of deleted nodes at op_depth=3 16:50 if you revert that deletion, then all the data siting at op_depth=2 "reappears" 16:53 Erik: well, I was talking about copying a tree which itself has been partially copied. then, delete the bit which has the copied subtree. 16:54 that bit is still in NODE_DATA, but no longer in WORKING so, there's no copyfrom_* correct? 16:55 meaning you can't make it reappear as deleted but that might be fine: it's a deleted wc-mod me: /me thinks... 16:56 if you delete an operation root, then yah... the source info is gone you have to re-do the copy the operations do not stack 16:57 Erik: that's my observation, yes. me: this is why op_depth is a unique key into NODE_DATA Erik: but it's in line with our handling of delete-of-local-change great. 16:58 then, I can start composing a mail. Don't expect it today though :-) me: hehe. not worrying about it :-P but yes: that is deleting a local change. 16:59 the harder point is the reversion of a local change. as we talked about, that "should" "reveal" a lower layer, but the NODE_DATA table might not have all the data. so we need some kind of marker for that. 17:00 thinking about it... when we construct the multiple op_roots for the mixed_rev, that also implies that we'll end up with multiple op_depth values within the NODE_DATA that is constructed, and that may mean that we need to enter these not-available nodes underneath the higher op_depth values, to be more concrete: 17:01 in op_depth=2, we add a bunch of nodes for the copied source nodes, and we also add <op_depth=2, newA/B/C> as a not-available node, then we add <op_depth=4, new/A/B/C> with the mixed-rev source data, 17:02 thus, when newA/B/C is reverted, we reveal the not-avail node (also note the UI implication: you cannot revert non-op-root nodes) 17:03 Erik: hmm. 17:04 you can revert non-op-root nodes, but only textually, is that the right understanding? tree-wise, there's no way to revert non-op-roots. me: ah. yes. you could revert content mods (text and props) on non-op-roots Erik: I think that sounds sane; i'm just wondering how many users will still understand tree versioning :-) 17:05 me: tho note that local-add nodes are all op-roots there is no "top of a tree of local adds". so you can revert any of those same for local-deletes (whether you're deleting BASE or copy-here or move-here nodes)
