> -----Original Message-----
> From: Stefan.Fuhrmann_at_etas.com [mailto:Stefan.Fuhrmann_at_etas.com]
> Sent: 2. desember 2008 13:59
> To: dev_at_tortoisesvn.tigris.org
> Cc: dev_at_tortoisesvn.tigris.org
> Subject: Antwort: RE: Bug with log cache?
> Kloster Oddvar <Oddvar.Kloster_at_sintef.no> wrote:
> > > > Hi,
> > > >
> > > > From time to time I encounter duplicated entries in the log
> > > dialog, as
> > > > shown in the enclosed image. This seems to be related
> to the log
> > > > cache, as it disappears when I turn the log cache off. The
> > > behaviour
> > > > has been different at different times:
> > > > - Usually, it happens consistently for a file, until I
> > > delete the log
> > > > cache, and it's gone
> > > > - Once, it happened more or less every second time I opened the
> > > > log dialog for a particular file
> > > > - This time, it happens only the first time I open the
> log after
> > > > deleting the log cache
> > >
> > > Just for the records: is the following sequence correct?
> > >
> > > * you closed all TSVN windows
> > > * deleted the log cache
> > > * called "show log"
> > > -> duplicate entries
> > >
> > Yup.
> While I did not reproduce this, I think r14725 may fix the issue.
> Please report back if the issue re-occurs.
> This is what happens:
> * log for some nested path populates the cache with
> a subset of the full history (o.k.)
> * log for a different path requires additional revisions
> to be fetched and added to the cache (o.k.)
> * since svn log has a significant latency, it is more
> efficient to issue a single request over a longer
> revision range even if a *few* revisions in that
> range are already in cache (o.k.)
> * results from svn log are passed directly to the log
> receiver / window (o.k.)
> * once the gap in the history is closed, the log receiver
> will be fed from cache again (o.k.)
> Problem: It seems that points 3 and 4 could result in
> revisions beyond the gap to be reported immediately and a
> second time when operation from cache resumes (not o.k.).
> This will probably only be possible, if
> * all relevant revisions at the lower (old) end of the
> history have already been cached earlier, and
> * those revisions are only few (<50) and small (<500 changes)
> The current fix will simply remember the last revision
> directly reported to the receiver and will never report any
> revision that is not older than that.
> -- Stefan^2.
The problem seems to persist, so I've gone and debugged a bit to find out what happens.
In CCacheLogQuery::InternalLog, the first test for dataAvailable fails, so it goes into FillLog, which returns with lastReported=1. During this FillLog, log data for revisions 7 and 1 is reported to the log dlg.
Upon retry, dataAvailable fails again, and it goes into FillLog a second time. This time, no revisions are reported to the log dlg. oldestReported remains 4e9 and on return lastReported is set to firstNARevision+1, in my case 9.
After this, the iterator has data, and revisions 7 and 1 are reported to the log dlg once more in line 1034.
Hope this helps.
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2008-12-08 11:51:42 CET