[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: log cache assertion

From: <Stefan.Fuhrmann_at_etas.de>
Date: 2007-05-24 23:30:13 CEST

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

This is an archived mail posted to the TortoiseSVN Dev mailing list.