A continuation of the previous conversation...
---------- Forwarded message ----------
From: Erik Huelsmann
Date: 2010/7/5
Subject: Chat with Erik Huelsmann
To: gstein_at_gmail.com
[...]
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)
Received on 2010-07-06 00:14:49 CEST