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

Re: Help in diagnosing make fsfscheck

From: Dirk Schenkewitz <schenkewitz_at_docomolab-euro.com>
Date: 2005-07-16 02:28:09 CEST

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

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