> >
> > Full error-free detection is only possible with full file compare on
> > every file in the working copy. Having said that, the current
> > algorithm says that if a file has a changed mtime it *might* be
> > changed and needs a full compare.
> >
> > The new algorithm which Peter Lundblad proposes is to *also* require a
> > full file compare if the file size changed. Instead of spending less
> > time in status, we will now spend more time in status (and err less
> > often on the side of false-negatives!).
> >
> > My proposal is that the full file compare on files which have a
> > changed file size only serves to filter out those cases where people
> > have edited keyword expansions or changed eols from CRLF to LF or vice
> > versa: extreme edge cases not worth the extra cost on the normal use
> > case.
> >
> > Hope that makes my reasoning (and the problem) clearer.
> But wouldn't that leave any files which change without changing the size
> marked as not changed? That would definitely not be good enough in my eyes.
> The chances that a file changes without changing its size are much greater
> than its mtime changing without the file changing (how does that happen anyway?)
Ah, but my implementation only prepends a size check before the
current algorithm: once a file has changed in size it's a 'sure mod',
while having a changed mtime means 'need to check'. So, with the
current algorithm, we detranslate a file, even though both size and
mtime may have changed, because we don't know its size has changed and
a changed mtime indicates we need to check for changedness. In that
situation - is my proposal - we shortcut the comparison, because 2
files of different sizes can't be equal.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 9 22:44:01 2006