[Philip Martin]
> 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.
And _that_ in turn is caused by a bug in apr where 'ctime' means two
completely different things. They should have used two different
fields in the stat structure to denote "file creation time" and "file
inode change time". Why they overloaded these two into a single field,
in a supposedly _portable_ runtime library, I will never know.
If any of you are apr developers, please consider adding two new fields
to apr_finfo_t, and deprecating the ctime field. Then it will be
possible to make subversion use newer(mtime,inode_mtime) if that is
indeed judged reasonable.
> I suppose we could store both ctime and mtime in the entries file,
> and check the file for modifications if either is different.
As that involves a format change to the working copy file, it's too bad
it wasn't proposed a week ago, before 1.4.0rc3 was rolled. That would
have been much more convenient, since the wc is already changing in a
most disruptive way.
> 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.
And yet people _will_ do it, and the author of recode even assures me
that people even _want_ this behavior! He didn't say why they want it.
- application/pgp-signature attachment: stored
Received on Sat Jul 15 21:02:02 2006