On 08/16/2013 04:14 AM, Julian Foad wrote:
>
> Branko Čibej wrote:
>
>> On 16.08.2013 04:48, Blair Zajac wrote:
>>> On 08/15/2013 08:01 AM, Julian Foad wrote:
>>>> I propose the following logical semantics of the versioned move
>>>> operation that is the basis of move tracking, independent of any
>>>> implementation.
>>>>
>>>> A versioned move of the node with node id “N”, with respect to two
>>>> revisions rX and rY (X < Y), shall mean:
>>>>
>>>> * Same node id. A node with node id N exists in rX and in rY. It
>>>> is “the same node”. It therefore has the same node kind. It may have
>>>> content modifications.
>>>
>>> If the contents change then it should get a new node-id.
> [...]
>>
>> You apparently misunderstand what a node-id is. It is not the primary
>> key to a revision of the node. [...] the primary key is:
>>
>> (node-id, copy-id, txn-id)
>
> To be fair, I was sloppy in my writing, and we have historically been sloppy with the term node-id. For example, the method root_vtable_t.node_id() returns a svn_fs_id_t which is a node-revision id (node-id, copy-id, txn-id), not a node-id.
>
> The key that I am referring to in the description of moves is (node-id, copy-id). Perhaps I will call it "node-copy-id" for short. I just checked and that term currently does not appear in the source tree. I'll update my docs. Thanks for pointing out the confusion
Thanks guys for clarifying, that makes me feel much better.
Blair
Received on 2013-08-16 15:48:33 CEST