Lübbe Onken <luebbe.tortoisesvn_at_googlemail.com> wrote:
> Hi Stefan Fuhrmann:
> you wrote:
>
> > 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.
>
> OK, but how does that fit with the TortoiseSVN versions that I've been
> running over the past two weeks?
It may have been caused by a bug that already fixed. The
respective code tried to eliminate redundant information
from the cache but could fail (only) under very specific
conditions.
> From a previous post:
> >> On the 25.8.2009 I installed TortoiseSVN r16974 over r16670
> >> On the 4.9.2009 I installed TortoiseSVN r17111 over r16974
> >> On the 10.9.2010 I installed TortoiseSVN r17148 over r17111
>
> The commits to the branch show up correctly in the log for all commits
> made with TSVN r16974 and before. They are wrong for TSVN r17111 and
> after. Is this just a coincidence? Was I lucky that the cache did get
> updated? I rarely use the revision graph, so chances that I updated the
> log cache this way are pretty slim. Yesterday I committed another bugfix
> to that branch and it didn't show up either.
I'm pretty sure it has nothing to do with the TSVN version
you used to commit the changes. My suspicion is that the
issue fixed in r17122 caused the invalid skip ranges entry.
Once they are 'corrupted', they can only be healed by adding
the missing revisions to the cache (e.g. showing the log
for the repo root). Because the problem was triggered only
by certain constellations between a path, its parent and
at least one sibling, I think it's been just coincidence.
> > Could you do a new export with the latest nightly and
> > send me the *.skipranges.csv? It is grouped (not sorted)
> > by path.
>
> Zipped file attached. It contains two skip ranges files. One *before*
> showing the log for the repository root and one *after*, which kind of
> repairs the log cache.
>
> I think the culprit is in the following rows of the *before* file:
> 2076,"/branches/ProjectA-Release",5753,1
> 2076,"/branches/ProjectA-Release",5756,4
> 2076,"/branches/ProjectA-Release",5762,2
> 2076,"/branches/ProjectA-Release",5777,1
> 2076,"/branches/ProjectA-Release",5812,1
> 2076,"/branches/ProjectA-Release",5819,4
> 2076,"/branches/ProjectA-Release",5831,9
>
> the skip ranges 5753-5812 look ok to me, because the skipped revisions
> are really not part of that branch. 5819,4 excludes r5821 and 5831,9
> excludes 5833 which were merged from trunk.
>
> The log for the branch is shown up to (and including) r5806 *before*.
> One thing worries me a bit. If 5831,9 means that nine revisions starting
> from r5831 are skipped, this can't be correct, because the highest
> revision number in the repo is currently r5834. OTOH r5833 is shown on
> the branch *after* the cache has been updated.
Thanks a lot for that data. Based on these files, I only needed
to verify that no 'beyond HEAD' entries could be added to the
skip ranges. After that, there were only two places where a
given entry could 'grow' (and thus reach beyond HEAD).
Though I think that r17122 fixed the root cause, I removed the
calling code entirely. As of r17200, the cache will show a slightly
worse performance on large repos in the average case. Best case
and worst case are unchanged and the potentially reduced performance
will hardly be noticed even in that 'average case'.
-- Stefan^2.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2396384
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-09-18 13:56:43 CEST