Hi, What about walking the revision history in smaller chunks? Given a repository history of revisions: r0, r1, ...., r100, the indexer would now diff [r0, r100] which can be resource intensive. What if it diffs by a window of size 10: [r0, r9] (mark), [r10, r19] (mark) and so on. This would not give out a 'continuable' session, but it has resilience, and optionally it could already use the intermediary index to serve queries instead of full traversals.
alex On Mon, Feb 20, 2017 at 3:14 PM, Davide Giannella <dav...@apache.org> wrote: > On 20/02/2017 13:44, Marcel Reutegger wrote: > > > > Instead of the revision, the implementation can also rely on a > > checkpoint that marks the snapshot of the repository as the basis of > > the large-tree-operation. > > I was thinking the same. We may rely on checkpoints and then store > additional info the checkpoint itself (can we?) for resuming operations. > I don't know if a diff computed against the empty (reindex) can change > tree order on multiple runs and we may need to store somewhere the > intermediate state of the reindexing so that by piking up: checkpoint, > last path and indexed data we may resume correctly. > > D. > > > >
