On 17.09.2013 13:12, Julian Foad wrote: > Branko Čibej wrote: >> On 17.09.2013 12:46, Philip Martin wrote: >>> I still don't understand. For a change like a text edit we always call >>> make-mutable and it always gives a new id, either changing the >>> revision-id or the copy-id. It's not clear to me that there should be >>> a make-mutable call before a move. >> The result of a move needs a new revision-id. Of course you have to make >> the node mutable before you modify it, and "move" modifies the node in >> the sense that it creates a new node-revision. > But why does "move" need to create a new node-revision of the moved node > itself (assuming the node isn't lazy-copied and isn't about to be modified). > Why shouldn't it just create a new reference to the existing old > node-revision? (Of course it needs to create a new node-rev of the parent > directory because the parent's list of children changes.)
Becasue otherwise you can't tell there was a move without comparing parent directory contents, and worse, you can't tell that the node was affected by a particular commit. And I hope you'll agree the latter bit of info is kind of important. Note that in the current FS implementation, there is not "node" object as such; there are only node-revision records, and the concept of a "node" is extrapolated from the node-id, just as a branch is extrapolated from the copy-id. Let me reiterate: the result of a "move" in the FS representation should be exactly the same as the result of a text or prop modification. I believe our top-down DAG model relies on that being the case. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
