On 17.09.2013 03:13, Stefan Fuhrmann wrote: > > On Tue, Sep 17, 2013 at 2:34 AM, Branko Čibej <br...@wandisco.com > <mailto:br...@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@r1 onto paths in tree2@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.3080...@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. br...@wandisco.com
