if all goes well, the log caching feature will be available from
the next nightlies onward.
This feature is "opt-in", i.e. disabled per default (see below).
Please test, whether there are any side-effects of the new code,
if log-caching is *not* activated. In particular:
* affected functionality: log, blame, rev. graph
* character escaping problems:
special chararacters in URLs, log messages etc.
* error handling: does TSVN report problems with the
repository access ("no server" etc.) properly?
To activate log caching, you must set
(00000000 will disable the feature, any other value enables it)
That setting will be evaluated every time a log request is
made and can be changed back and forth w/o corrupting
the cache, for instance.
With log caching enabled, please look for the same type of
potential issues as listed above. Also, compare with non-
cached results. On x64 this is particularly simple: use a
production version of TSVN for x64 and the nightly for win32.
While the cache engine is extremely fast, its full potential
is yet to unleash. Known performance issues:
* log performance will be exceptionally low, if there are many
"gaps" in the cached data: for each relevant gap there be
an individual SVN server request. Example: assume a number
of active branches. "log /trunk" will only fill the cache with revs
that touch the /trunk. A following "log /" will have to fill 100s or
1000s of gaps.
* latency is limited by dialog initialization (~1 sec) and initial
server handshake (~1 sec)
* thoughput is limited by UI update (> 1000 revs / sec)
Yes, there is still a lot to be done and some advantages may
not be realized during the 1.5.x development (too complex /
risky while trying to stabilize the basic feature).
Received on Sun May 20 13:12:54 2007