Hi Stefan,
> While doing some testing with the cache, I came to an assertion which I
> don't know how to solve. You are more familiar with the log cache code,
> so I put together a reproduction recipe for the assertion
There was actually an edge-case that I did not handle properly.
My wrong assumption that got caught by the assertion is fixed in r9548.
For the sake of documentation, the following describes the problem:
(1) The log cache stores (requested and) received data only.
Revisions that have not shown up in some log request are
reported as "data not available". Technically, their
revision number is mapped to the NO_INDEX revision index.
(2) Within the log cache, paths are represented as indices
to an entry in a/the CPathDictionary instance. To reduce
the amount of data to store, only those paths that are
mentioned in a change list of a cached revision are put
into the path dictionary.
"Mentioned" means as path, copy-from-path or as a parent
of any of them. This info is sufficient to create all
possible logs from a complete log of the repository root.
(3) When receiving a log for e.g. /branches/1.4.x, there will
be large "gaps" of uncovered revisions. Unless those gaps
get filled, there would be no way to reproduce the log
for /branches/1.4.x from the cache some times later because
the gaps might "anything", including changes affecting
/branches/1.4.x.
Problem: we just don't "remember" that they can't.
In fact, we *do* remember (i.e. store) that information.
It's in the CSkipRevisionInfo instance: For every log
we received, it stores the path along with the list of
"gaps" in the revision list received.
An entry means that for this path and all its children
there will be no log information in the respective
revision range. Log iterators use that information to
skip revisions that are not in cache.
Optimization methods reduce the CSkipRevisionInfo by
removing redundant info (parent path vs. sub-path;
remove ranges that are covered by cached log info).
(4) Skip revison info is persistent in the log cache file.
Therefore, only paths available in (2) can be represented.
(5) In your example, file1 got moved around quite a bit
but never showed up in the log on those new places.
Therefore, no cache-based path is available for it.
Hence, we cannot add the skip info for it.
We also can't just store it with it's parent path
because that might hide changes in file2, for instance
(depending of the completeness in (1)).
O.k. that's enough for today. But since I can be quite
unresponsive at times, it will help to get others on speed
soon ...
-- Stefan^2.
Received on Thu May 24 23:30:22 2007