[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Moves in FSFS

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Tue, 17 Sep 2013 12:43:21 +0100 (BST)

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 itself (assuming the node isn't lazy-copied and isn't about
>> to be modified).  Why shouldn't it just create a new reference to the
>> existing old node-revision?  (Of course it needs to create a new node-rev
>> of the  parent directory because the parent's list of children changes.)
> 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.

> Note that in the current FS implementation, there is not "node" object
> as such; there are only node-revision records, and the concept of a
> "node" is extrapolated from the node-id, just as a branch is
> extrapolated from the copy-id.
> Let me reiterate: the result of a "move" in the FS representation should
> be exactly the same as the result of a text or prop modification. I
> believe our top-down DAG model relies on that being the case.

I assume you mean "the same" only in terms of new id assignment, not (for example) that it would necessarily create a new representation of the data content.  I'd be interested to see what part of the DAG model relies on that.

- Julian
Received on 2013-09-17 13:45:33 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.