[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: Blair Zajac <blair_at_orcaware.com>
Date: Fri, 16 Aug 2013 06:47:52 -0700

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.

Received on 2013-08-16 15:48:33 CEST

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