On 11/7/06, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> 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.
Well, that'll give us fewer false negatives, without the extra false
positives, but it will gain us no speedup: all files which are marked
'maybe-changed' need to be detranslated to test eol- and keywords-only
changes. My point is that these are sufficiently edge case not to
require full detranslation on status: 'normally' only content changes
will have occurred.
Hope that clarifies both the change and the consequences.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 7 23:45:13 2006