Re: svn doesn't report modified file when timestamp has not changed

Greg Hudson <ghudson@MIT.EDU> writes:

> Ben, your answer is boilerplate, and suggests that you didn't completely
> read or understand Vincent's message. The proposal is not to scan every
> file's contents on each out-of-date check, but it take into account the
> inode change time on Unix (as we apparently once did, years ago).

I think the old algorithm looked at both ctime and mtime and used
whichever was the greater as the 'text-time'. This caused problems on
Windows as it is possible to have ctime much greater than mtime and
then text modifications, which only affect mtime, don't cause the
'text-time' to change and then modified files get treated as
unmodified.

I suppose we could store both ctime and mtime in the entries file, and
check the file for modifications if either is different. We would
still have the problem that ctime is something different on Windows
and Unix, but I don't suppose that would matter. One argument against
this is that ctime doesn't usually change on Windows. Another
argument against is that Subversion doesn't version the things usually
affected by ctime on Unix.

Looking at the original problem: yes, it's possible to modify a file's
contents and change only the ctime, but that's not a good idea. Don't
do it! It will confuse make for a start, and so for any sort of
'conventional' source code it's a bad idea.

I'm not against using both ctime in addition to mtime, but it's low
priority as far as I am concerned. Much more useful would be to start
using working file size in addition to mtime.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org