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
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.
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
Received on 2013-09-17 03:40:28 CEST