On 07/30/2011 03:18 AM, stsp_at_apache.org wrote:
> Author: stsp
> Date: Sat Jul 30 01:18:20 2011
> New Revision: 1152410
>
> URL: http://svn.apache.org/viewvc?rev=1152410&view=rev
> Log:
> Store moved-to relpaths in the BASE tree (op_depth = 0) instead of
> nodes_current. All move operations are relative to the BASE, so having
> moved-to information in op_depth layer 0 is semantically more correct.
I've been thinking some more about this, and I'm quite 50/50 on which level
is best suited for moved-to (op_depth == 0 vs. op_depth > 0). (If a BASE
node was moved, there always is an op_depth > 0 node available.)
I thought I'd jot some details of the choice down so others can have their
opinions.
When storing moved-to in op_depth == 0 (as this patch introduces),
- the meaning of the column is more intuitively clear. The moved-to
information tells you where the BASE was moved to locally. Straightforward.
- but on moves and reverts, the op_depth==0 row needs to be updated. So
- the op_depth==0 rows' moved-to columns can be corrupted by interrupted
operations. Yet this is easily remedied by a revert, clearing that column.
If moved-to is stored in op_depth > 0,
- it's true to the idea that a full revert is simply wiping all op_depth > 0
nodes away (is that still true up to now?)
- but the meaning of the column moved-to becomes more complex to explain and
code. An op_depth>0 row's moved-to column does not refer to any new node
added at the given op_depth, but always refers to the (unrelated) BASE node
with the same path. Say alpha was replaced after a move-away:
mv alpha beta
touch alpha; svn add alpha
Then there is a new op_depth=1 node for alpha, representing the new node
that has nothing to do with the history of BASE. But, confusingly, the
location where the BASE was moved-to is still saved in the row for that new
node.
- So code needs to take care that the moved-to column in op_depth>0 rows
remains unchanged, i.e. remains tied to that specific path, no matter how
much adds, deletes, moves etc. happen on the nodes of that path. Ugh.
So it's a dilemma, and I can't know which advantage is cooler.
> It will also make it easier to deal with stuff like cyclic moves and
> replacements later. E.g. before this commit moved-to information was lost
> if the delete-half of a move was replaced, and fixing this as a special
> case in the code that adds the replacing node would have been ugly.
^ here is one of those situations that generates ugly code.
> Also, clear moved-to relpaths from the BASE tree during 'revert' so
> we don't leave phantom moved-to information in the DB (are there any
> other places where we need to clear it?).
^ here would be the remedy to any interrupted operations involving moved-to.
And at the same time this update of op_depth==0 rows during revert was not
necessary before this patch.
~Neels
Received on 2011-08-01 15:05:17 CEST