Bug#376103: subversion: svn doesn't report modified file when timestamp has not changed

[Vincent Lefevre]

severity 376103 grave
thanks

On 2006-06-30 06:29:29 -0500, Peter Samuelson wrote:
> I find it hard to put into words just how broken I think this is, and I
> hope it's obvious enough that I don't have to.  You just _don't_ modify
> files on a Unix filesystem and then hide the fact that you did so,
> unless the user has specifically indicated that there's a reason to do
> this - as with 'cp -p' or 'rsync -t' or 'touch -t'.  You don't make
> this the _default_ behavior!

I agree this shouldn't be the default. But...

> I'm copying this bug to recode.  In my opinion, 'svn' and 'make' should
> be entitled to assume that the user has been honest about modifications
> of her own files.

I agree about make, but concerning svn, one can't rely on that.
Mutt does exactly the same thing as recode when modifying a mailbox
(in mbox format). And users may want to handle their mailboxes with
svn. So, the problem is not specific to "recode". The "mv" utility
has the same problem too. For instance, do a "svn co ..." (several
files should have the same timestamp, except on slow machines),
then, in the checked out directory: "mv some_file other_file"
(where other_file also exists and have the same timestamp), then
"svn st". "unzip" and "gzip" could lead to similar problems too.

> > Looking at the timestamp (mtime) isn't sufficient to quickly decide
> > whether a file has been modified. Under Unix, the ctime should be
> > taken into account too (and/or possibly the inode).
> 
> What the #*&$@ is the mtime for, then?  Is it just a pretty but useless
> field for 'ls -l' to display?  In my opinion, the whole _point_ of the
> mtime is to tell you when a file was modified.

I agree for *some* commands such as "recode", but for other commands,
this makes sense to let the mtime as it is, in particular for "mv".

> In summary, the patch you want me to apply is quite simple, but in
> essence you're asking me to tell svn to ignore all mtimes in favor of
> ctimes.  And really, it seems to me that the rationale for doing this
> also applies to every other Unix program -- and thus implies that the
> mtime field shouldn't exist at all.

Other Unix programs won't lead to lost data because of a different
mtime (unless the user explicitly tells the command to consider
mtime, e.g. with "cp -u").

> It's also not a patch I can send upstream, as it will do the wrong
> thing on Windows and OS/2.  This increases the annoyance factor even
> more.

Subversion doesn't need to do the same thing under Windows and OS/2
(Subversion already has features that depend on the OS, e.g. symlinks
support).

-- 
Vincent Lefèvre <vincent at vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA