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

[Peter Samuelson]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-subversion-maintainers/attachments/20060630/de05c9e9/attachment.pgp