Re: Moves in FSFS
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Tue, 17 Sep 2013 11:55:07 +0100 (BST)
>> Branko Čibej <brane_at_wandisco.com> writes:
A different id (than node-id+copy-id) is needed because I prefer to
Some important move-tracking query APIs are ones which will map between paths in one revision and "corresponding" paths in another revision. For these purposes I believe the abstract model we need to present is one in which copying a directory creates new lines of history ("node-lines") for all nodes in the subtree, even though their content may not have diverged yet. In other words, for the purposes of a query that asks "where" (at what path) in revision REV2 we would find the node corresponding to that at PATH1_at_REV1, it should behave the same *as if* copies were always full copies and never lazy. (Conversely, in merging, for the purpose of finding a common ancestor of changes to be merged, it may be easier to work with the late branching / lazy-copy model, as the nearest common ancestor can be nearer.)
The "node-line" concept is merely a tool to aid in the definition of the semantics. I am not suggesting here that the node-line-id should be transmitted to the client or used in the editor APIs. (Those are separate discussions in which we may or may not want to use such a concept.)
Do you object to my using this invented concept as a tool within the semantic specification, or do you object to this abstract concept being made concrete and stored and exposed? Do you disagree with the semantics I defined, or find it hard to interpret, or is it that you would prefer to describe the same thing in a different way? I'm not clear.
The same semantics could of course be defined in other ways. However the definition as I've written it clearly doesn't work if we just write (node-id, copy-id) in place of (node-line-id). Here is an example of how it makes a difference.
branch the trunk:
It certainly must not report a simple (node-id, copy-id) correspondence, because that would look something like:
Branko Čibej wrote:
Harder in the sense that a naive map from each node-line-id to each reachable path in the revision would require adding N entries to the map when copying a subtree of N nodes, thus making copy no longer O(1). To maintain O(1) copies we'd need something cleverer.
In my present definition of move semantics, the ids used in this map would be what I call "node-line" ids, not the raw (node-id, copy-id) pairs. How copy-ids work is thus irrelevant to me. (Reading between the lines, I think with your questions about how copy-id assignment works you meant to question how copy-id could possibly be used to answer move tracking queries, whereas Brane answered them as direct questions about how copy-id assignment currently works.)
This is an archived mail posted to the Subversion Dev mailing list.