On Tue, Sep 17, 2013 at 2:34 AM, Branko Čibej <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.
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
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.
Received on 2013-09-17 03:14:28 CEST