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
>> 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
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
Received on 2013-08-16 05:09:50 CEST