[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: Branko Čibej <brane_at_wandisco.com>
Date: Sun, 29 Sep 2013 21:04:03 +0200

On 29.09.2013 19:34, Stefan Fuhrmann wrote:
>
> On Sat, Sep 28, 2013 at 12:36 PM, Branko Čibej <brane_at_wandisco.com
> <mailto:brane_at_wandisco.com>> wrote:
>
>
> Exactly. And this is the second issue of the two I mentioned: in
> order to make merge aware of moves, as opposed to copies, you have
> to be able to detect that two distinct path_at_revision in fact refer
> to the same branch of a node -- which is exactly the (node-id,
> copy-id) pair, and that /is/ sufficient for the purpose. So again,
> there's no need to invent another branch-tracking identifier.
>
>
> Sigh. The (node,copy) pair *alone* cannot be sufficient to map
> move sources and targets.

That's not the case I'm talking about. I believe we already came to the
conclusion that, in FSFS, in order to answer the "what node got moved"
question, we need help from the changes list. However I maintain that we
don't need any extra info to answer the question, "are these two node
revisions on the same branch."

> In-depth reason: Once you accept that the move semantics as
> suggested by Julian's definition is what you want to support, *any*
> ID scheme must either be isomorphic to the node-line ID approach
> or a true superset of it. In the latter case you must provide auxiliary
> rules (can be implicit) that effectively limit the superset to the
> original.
> Otherwise, your implementation does not match the definition.

As I said, this is a different issue.

The jury's still out on whether I accept that definition of move
semantics or not; but in any case, detecting moves and detecting
sameness are different problems for different use cases.

-- Brane

-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com
Received on 2013-09-29 21:04:45 CEST

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