Re: Definition of Node-Line-ID

On 17.09.2013 03:13, Stefan Fuhrmann wrote:
>
> On Tue, Sep 17, 2013 at 2:34 AM, Branko Čibej <brane_at_wandisco.com
> <mailto:brane_at_wandisco.com>> wrote:
>
> On 17.09.2013 01:19, Stefan Fuhrmann wrote:
> > Hi there,
> >
> > After two hours of analysis, it seems that I have found
> > the correct definition for the "node line ID" as required
> > by Julian's move API design
>
> I thought we already determined that the concept was not
> necessary. What
> did I miss?
>
>
> Hm. I wondered what I missed, scanned the
> posts from the last few days and could not find
> a statement that IDs were not necessary to
> be able to track renames / moves.

There was no such statement. But there's no need to invent a new ID.

> IMO, we need an operation / query that maps
> paths in tree1_at_r1 onto paths in tree2_at_r2 (details
> like tree vs. dir etc. may vary).
>
> I see two ways to implement that operation:
>
> (1) history scan
> (2) having / defining IDs and matching those
>
> From an operational complexity POV, both may
> actually be equivalent but that would depend on
> implementation details.
>
> My gut feeling is that (2) is more efficient in the
> majority of cases and my initial post showed that
> no FS-layer ID is fully sufficient (but may be useful
> for internal optimizations and quick checks) for it
> as long as there is lazy copying.

Indeed, (2) is more efficient, but the assumption that (node-id,
copy-id) are not sufficient for that seems to be incorrect. See my
response to the "Moves in FSFS" thread, message-id
<5232EBE7.3080205_at_wandisco.com>.

The only argument for a new ID in that thread is this:
> Another way to provide the moves between arbitrary revisions is to have
> an id to path map per revision which allows the FS to find the path
> associated with a given id. However with lazy-copy this map is harder
> to implement.

I'd hardly call an unsubstantiated "harder to implement" an argument,
and I explained in that post why the other apparent problem with lazy
copying is not in fact a problem. I'd rather see someone respond to that
and prove me wrong before we go inventing a new concept that we don't need.

-- Brane

-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com