Ben Collins-Sussman wrote:
> Looking at your tests.log, it seems that the test failures are related
> to situations whereby a file should be locally modified, but subversion
> isn't detecting the modification.
>
> Are you perhaps running the tests on a FAT filesystem? FAT has a 2-
> second time resolution for timestamps, so it's possible that a script
> can append to a file and then ask 'svn' to stat the file all within 2
> seconds. Subversion sees no change in timestamp, so it assumes that
> the file hasn't changed.
:(
Sorry to nag again, but - knowing that FAT has 2s time resolution, the
algorithm you described somewhere else on the list:
>> stat working and textbase files.
>> if (mtimes of working and textbase are equal):
>> return NOT_CHANGED;
>> else if (filesizes of working and textbase are unequal):
>> return CHANGED;
>> else
>> compare the files byte-by-byte. /* very slow */
is rather prone to give false negatives. And then: Better "very slow"
than wrong.
It is high time to have an alternative algorithm that can be selected
via an entry in the config file of a repository, so that people could
go for a really fast one on unix (as it is now) or a slower one on FAT.
The abovementioned algorithm is IMO buggy. It would be better to do:
stat working and textbase files.
if (mtimes of working and textbase are not equal):
return CHANGED;
else if (filesizes of working and textbase are unequal):
return CHANGED;
else
return UNCHANGED;
That would be a bit better than it is now (less false negatives) and
would be even faster than now. And please note that you don't get any
false positives, because if a user just 'touch'ed a file, he probably
WANTS to bump up the revnum. If the actual data is not changed, so
what?! Xdiff will find out and make a very cheap new revnum.
But an industrial-strength algorithm has to be exactly as follows:
stat working and textbase files.
if (mtimes of working and textbase are not equal):
return CHANGED;
else if (filesizes of working and textbase are unequal):
return CHANGED;
else
compare the files byte-by-byte. /* very slow */
I admit that it is unlikely to hit the 2s-problem when only humans are
involved, but what if some script is used to checkout something, make
a small change and commit?
Best regards
Dirk (now going into a holiday) :)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jul 16 02:29:41 2005