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

[Vincent Lefevre]

On 2006-07-01 16:10:58 -0500, Peter Samuelson wrote:
> [Vincent Lefevre]
> > mv *must be* supported. It's a Unix command and the user is allowed to
> > use it.
> 
> That's a poor argument - the user is allowed to use 'rm -fr .svn' and
> subversion can't recover from that state.  It's equally plausible, in
> fact, that a user who doesn't know how to use svn will do the latter as
> the former.

Wrong! Subversion does *not* allow to do 'rm -fr .svn' (the Subversion
book says that .svn is a directory internally used by Subversion).
Moreover, if the user does this (e.g. by mistake), the error will be
reported (while "svn st" does not report any error if some file has
been modified and the timestamp is the same).

The Subversion book says concerning changes in the working copy:

  To make file changes, use your text editor, word processor, graphics
  program, or whatever tool you would normally use.

And "mv" is one of these tools.

> > 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).
> 
> It's still a corner case that users who know how to use the software
> should never do.

The fact that you *think* that mv is bad does not mean that users
should not use it. There may be good reasons to use mv and you should
not dictate the users what to do.

And again, this problem is not specific to "mv". MUAs also set the
mtime to the old value when modifying an mbox file (for some technical
reason).

> > Yes, this is a documented feature (which can be disabled), whereas in
> > subversion, it is not a feature; for instance, "svn help st" says:
> 
> You're hung up on whether or not it's documented that some process uses
> the mtime.  Well, I could document that subversion uses the mtime -
> would that make you happy?

At least it would be better than the current behavior: the user would
know how Subversion behaves and would not lose data (except if he
doesn't read the manual, but then this would partly be his problem).

But then there would be a wishlist bug to have a "safe" svn st, etc.
Some programs have such an option (e.g. rsync --ignore-times).

> I'm guessing it will not, because that isn't the real issue. The
> real issue is whether, in your view, there is _any_ legitimate use
> of the mtime field in _any_ application. And if so, how that differs
> from subversion's use.

It's not *my* view. But also the view of those who wrote mv, designed
the mbox format and so on. Even Subversion sometimes sets the mtime
back in the time (e.g. with svn export).

> > 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).
> 
> Because subversion doesn't store both the ctime and the mtime, so you
> have to pick one.  Obviously you can't pick ctime if it means file
> creation time.

Subversion could be modified to store both (when ctime is supported).

> > > 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.
> 
> You're dodging the question, because you think 'find -mtime' is an
> exception because it refers explicitly to the mtime field.  OK, so what
> about 'find -newer'?

By definition, "newer" refers to the mtime timestamp. RTFM.

> Do you think it is a bug or a feature that it uses the mtime?

This is the definition. This can't be a bug here.

> Never mind whether the manpage mentions that it's the mtime (it
> does, but only in passing, to explain the symlink case),

BTW, the man page is not the official manual. The info file is, and
this is quite explicit: "2.3.2 Comparing Timestamps". Of course, if
you think that the manual (or the man page) is not clear, you can
report a bug...

> which do you think it _should_ use, for a desired feature of "find
> files modified more recently than X"?

Well, I see "find" as a rather low-level tool, i.e. it is closely
related to the inode fields. And it is rather unintuitive for some
tests (e.g. with -atime +1, and there's even an example about that
in the man page). Anyway the fact that "find" has deficiencies does
not imply that Subversion is allowed to have ones too.

> > 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.
> 
> You're asking for a working copy format change, and that's something I
> refuse to diverge from upstream about (upstream will change the format
> in 1.4.0, by the way, but not in the way you want).  For one thing it's
> a bad place to diverge from upstream in principle, for another thing
> I'd have to deal with the headache of being able to read both old and
> new working copies.  Not going to happen.

I'm not saying that you should diverge from upstream. When there's a
bug, it should be fixed upstream too (but as I was using the Debian
package, I don't always know what is fixed upstream).

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