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.
>
> I have a vested stake in this since our asset management system backed
> by svn caches in memcached the result of many svn_fs_*() functions by
> node-id. Our system does three cache lookups:
>
> time -> revision
> (revision, path) -> node_id
> (node_id, function_name) -> result
>
> Doing this allows me to take a lot of load off the svn backend RPC server.
You apparently misunderstand what a node-id is. It is not the primary
key to a revision of the node. In our current numbering scheme (and in
any future planned such scheme that I can currently think of), the
primary key is:
(node-id, copy-id, txn-id)
(you can think of the last element as the revision id, but the primary
key has to remain unique in the presence of uncommitted transactions).
Given a node identified by (node-id, copy-id, txn-id), and ignoring the
fact that our current copy-id inheritance cannot support moves in
general, copy and move differ in exactly one particular:
* copy creates (node-id, new-copy-id, new-txn-id)
* move creates (node-id, copy-id, new-txn-id)
In other words, both copy and move result in a new primary key for a
node revision, but copy creates a new branch whereas move does not.
I expect that your system uses the primary node-revision key, not the
node-id.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
