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

[Vincent Lefevre]

On 2006-06-30 20:33:08 -0500, Peter Samuelson wrote:
> mv within a subversion working copy isn't supported anyway; what you do
> instead is 'svn rename' or 'svn copy'.

mv *must be* supported. It's a Unix command and the user is allowed to
use it. I'm not saying that I want that same behavior as "svn rename".
I just expect that if I do "mv some_file other_file", then subversion
should report some_file as missing and other_file as modified (if the
file contents were different).

> > 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?

Yes, this is a documented feature (which can be disabled), whereas in
subversion, it is not a feature; for instance, "svn help st" says:

  With no args, print only locally modified items (no network access).

i.e. "modified items", not "modified mtime".

> > 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".

Then apr is very badly designed. The creation time is something
completely different than the inode change time. So, apr shoudn't
present them under the same name. Anyway, why wouldn't this work
on Windows and OS/2? If the creation time is modified, this means
that the file is different (well, should be, but subversion then
looks at the contents anyway); and if the creation time is not
modified, then the behavior would be the same as not looking at
it (i.e., the same as before).

> 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.

I'm not saying that. I'm saying that mtime is a user field, that can
be set by some programs for a good reason. Don't you agree that "mv"
should keep the old mtime? Some commands (e.g. find -mtime, make, cp
-u) *explicitly* use the mtime, as documented. This is not the case
of subversion, whose goal (as documented) is to consider the file
contents. Any optimization should be safe. So, in addition to mtime,
subversion should look at other fields. I'm not sure whether ctime
is sufficient or if subversion should look at the inode number too.

-- 
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