severity 376103 normal thanks [Vincent Lefevre] > > 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.
I'm still not convinced that svn is a special case. It seems to me that if you lie to the system about your file modification times, lots of utilities behave unexpectedly, and in all cases it's the user's own problem. > > 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". mv, and cp -p, and rsync -t, all have in common that when they write a file with an incorrect mtime, it is because the contents of the file are unchanged from another file with a matching mtime. mv within a subversion working copy isn't supported anyway; what you do instead is 'svn rename' or 'svn copy'. > 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"). They'll do things just as bad. 'find -mtime -5' will not find files modified in the past 5 days. 'make' will not rebuild programs whose C files you have changed. 'tar --newer-mtime' will not back up files which have changed more recently than your previous incremental backup. Do you think any of those effects are desirable? > 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). The problem here is that, while subversion uses a portability library called apr, apr itself has different behavior with respect to ctime on different platforms. On Unix and Netware, it presents inode change time. On Windows and OS/2, it presents file creation time (which doesn't exist at all on Unix). Goodness only knows what it does on OS/400. I still can't send this patch upstream, it's too ugly to make it depend on "whether the ctime field is available and means what we think it means". Please also explain why you think the mtime field is useful at all. I don't understand your logic that it's useful for some things but not for others. If you'd like to argue that mtime should be ignored in all unix applications and only ctime used, that would be more consistent. Thanks, Peter
signature.asc
Description: Digital signature
