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

Re: Caching text-size in the entries file

From: Michael Haggerty <mhagger_at_alum.mit.edu>
Date: 2006-11-07 15:46:59 CET

Erik Huelsmann wrote:
> On 11/6/06, Erik Huelsmann <ehuels@gmail.com> wrote:
>> On 11/6/06, Peter Lundblad <plundblad@google.com> wrote:
>> > Erik Huelsmann writes:
>> > > Ah, we already have a speed-vs-correctness tradeoff in status: we use
>> > > mtimes instead of filecomparison or hash calculation. BTW: I do feel
>> > Yeah, but I think we need to be careful when making the heuristic
>> worse.
>>
>> Right, but what I hope to do is reduce the number of false negatives:
>> I assert most files which are modified (but do not have their
>> timestamp changed) won't have modified keywords or eols only. Rather:
>> I think having modified eols-and-keyword-expansions-only is an edge
>> case rather unlikely to happen. Whereas we have seen cases where
>> timestamps were kept constant (making the changes undetected).
>>
>> Currently our algorithm doesn't know any false positives, but it has a
>> chance for false negatives. I'd rather see that the other way around:
>> false positives are correctable with an 'svn revert' or 'svn cleanup';
>> false negatives don't have a cure.

What if Erik's new algorithm is used to detect
files-that-might-be-modified, then those files are double-checked using
the more expensive algorithm? I assume that in most use cases, at most
a small percentage of files are changed when 'svn stat' is run.
Therefore this should give almost as large a speed win without any
downsides.

Michael

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 7 15:47:22 2006

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

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