[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

NODE_DATA (part 2) (was: Chat with Erik Huelsmann)

From: Greg Stein <gstein_at_gmail.com>
Date: Mon, 5 Jul 2010 18:13:06 -0400

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

This is an archived mail posted to the Subversion Dev mailing list.