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

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

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2006-07-15 19:03:54 CEST

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

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
Received on Sat Jul 15 19:04:40 2006

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.