Re: Moves in FSFS
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Wed, 18 Sep 2013 10:16:08 +0100 (BST)
Julian Foad wrote:
I'd like to withdraw my argument. I am merely curious. I don't know enough about FS internals and if it needs to assign a new node-rev-id then so be it, I can accept that for now without having to understand exactly why. I shouldn't need to care about these details right now because I should be concentrating on the API semantics and not on how FSFS achieves them.
On the subject of the API, I'd like now to look at defining the FS API for moves.
We have been discussing whether the commit editor (and also the update editor) should use a sequential model (ordered, and referring always to the current state) or a commutative model (unordered, or less strictly ordered, and referring always to the initial state) for moves.
Editing a FS transaction is naturally a sequential, stateful activity. A transaction is, after all, the embodiment of a state. However, the FS layer has the luxury of guaranteed easy access to the initial state at all times, and so it seems that we can still choose either model for the FS layer API. So I'm going to look next at how they compare.
In <http://wiki.apache.org/subversion/MoveDev/MovesInFSFS> I have already written a brief specification for an svn_fs_move() API, assuming the sequential model,
Talking with Brane the other day, we discussed that my analysis of move semantics so far has been rather framed in the context of one particular representation or another (move-away, move-here, for example) and he would like to see a more neutral description, a mathematical model if you like. This should make it easier to compare the pros and cons of different representations without bias, and for example to see whether my "node-line-id" concept is unnecessary. So I'm also going to take a stab at such a description.
This is an archived mail posted to the Subversion Dev mailing list.