Re: Moves in FSFS

Julian Foad wrote:
> Branko Čibej wrote:
>> On 17.09.2013 13:12, Julian Foad wrote:
>>> But why does "move" need to create a new node-revision of the moved
>>> node [...]?  Why shouldn't it just create a new reference [...]?
>>
>> Becasue otherwise you can't tell there was a move without comparing
>> parent directory contents, and worse, you can't tell that the node was
>> affected by a particular commit. And I hope you'll agree the latter bit
>> of info is kind of important.
>
> You can tell in other ways.  (1) you can find it in the "changes" list
> for the revision. (2) if you have an index of (revision, node-line-id)
> to path, you can look up the node-line-id in that.
>
> But I suppose you're well aware of that, and so presumably you mean
> something more specific: that from a history walk (as in "log") of the
> particular (node-id, copy-id) across a revision range, you want to discover
> a point where it says "I was moved", like we discover an entry that says
> "I was copied", and you want to get that info efficiently, so you want
> to have the relevant revision number encoded into the id.  I agree users
> would expect to see an entry for the node in "svn log"; I don't know for
> sure that it needs a new node-revision-id in order to accomplish this
> efficiently.  I agree it's a possible and reasonable solution.

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,
but that
may not be the best option.

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.

- Julian
Received on 2013-09-18 11:17:05 CEST