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

Re: Semantics of Move

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Fri, 16 Aug 2013 12:14:43 +0100 (BST)

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.

- Julian
Received on 2013-08-16 13:15:50 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.