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

Re: Log Cache problem on a branch doesn't show latest revision

From: Stefan Fuhrmann <stefanfuhrmann_at_alice-dsl.de>
Date: Fri, 11 Sep 2009 13:21:29 +0200

Lübbe Onken <luebbe.tortoisesvn_at_googlemail.com> wrote:

> you wrote:
> > * Show "Details" for the same cache. Is "Skip Ranges"> 0?
>
> Yes
> > Is "Max Revision" equal or greater than the missing one?
>
> Yes
>
> > * Does "Update" (same place) fix the problem?
> > If so, restore from backup.
>
> Yes

That limits the culprit pretty much to the skip ranges.
If they only weren't that important for performance,
I would have dropped them long time ago ..

> > * Is "Settings -> Log Cache -> HEAD Timeout" set?
> > If so, set it to 0 and retry.
>
> it is set to "poweruser" :) means 300. Retry what? I set it to 0 and
> "showed log" again, but the revision doesn't appear. Only when I press
> Ctrl-F5

That rules out problems with the HEAD revision cache.

> > * Go to the CSV files exported earlier. Open *.revisions.csv
> > in an arbitrary text editor (it is sorted by revision).
> > Does it contain an entry for the missing revision?
>
> No

I suspect that the skip ranges mark the (missing) HEAD
revision as 'not relevant for that path', so the repository
query will either start with a much smaller revision number
or stop above it.

> > * Log for the project root (e.g. via repo browser).
> > Does the revision show up?
>
> A strange thing happens here. It looks like it is something
> "timing/timeout" related. FYI, the log cache is still in HEAD Timeout 0
> mode.
>
> First try, fire up the repo browser:
> The revision is not visible for "/branches/branch-x", but in every level

> above. So it is visible for "/" and "/branches".

Yet another sign that the "skip ranges" are to blame.

> Then "quickly" after having shown the log for "/" in the repo browser:
> Show log in repobrowser for "/branches/branch-x" -> revision not there
> Showed log in working copy -> revision not there
>
> A "few" seconds later:
> Show log in repobrowser for "/" -> revision there
> Show log in repobrowser for "/branches/branch-x" -> revision *there*
> Showed log in working copy -> revision *there*
>
> I can't tell if the second "show log" in the repo browser root triggered

> some event or if it just needed a few (15-20) seconds to consolidate and

> save the data, and the revision was available from now on...

Only the first application gets write access to the
respective log cache file. Others will not store
their updated cache info nor will they see updates
from other clients. Except for a performance penalty,
there is no functional drawback to any client as long
as they work correctly.

That gives a perfect explanation for what you have
been seeing: As long as the process showing the root
log wasn't closed (plus a second or two to write the
data to disk), other instances still saw the old data.

> > * Does the revision graph show all revisions (make sure
> > to show all revisions)?
>
> Yes it shows all revisions, but it also looks like the graph fetches all

> revisions before it paints itself.

Correct. But it first updates the log cache and used
the latter as its only data source. The log dialog,
OTOH, will pass the svn log query result directly
to the UI and only copy it to the log cache.

That's why <CRTL>-<F5> gives the proper log (svn query
without taking existing cache data into account) and
a following <F5> (update head, work from cache when
possible) will show incomplete data.

> Cache is repaired afterwards, like after update in the settings dialog
> (same size, I didn't compare the files).

Log cache size may vary as the data is indexed, not
sorted. The following data compression will give
different results depending on the order.

> I still have the cache backup file, so I can play around with it a bit
> more, but now I'm off -> home.

I'm somewhat busy these days. Therefore, I could not
afford to fully review and analyze the "skip ranges"
code. Instead, I extended the CSV export to dump the
skip ranges data as well.

Could you do a new export with the latest nightly and
send me the *.skipranges.csv? It is grouped (not sorted)
by path.

You can search / replace path names with 'A', 'B' etc.
If the file is too large, you may remove all entries,
except for /trunk, /branches, /branches/'branch-x' and
/branches/'branch-x' sub-folders. Very old revision ranges
can be removed as well. However, I would prefer to get
the complete file.

-- Stefan^2.

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2393589

To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-09-11 13:21:44 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.