On 07/30/2011 03:18 AM, s...@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
signature.asc
Description: OpenPGP digital signature
