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

[Peter Samuelson]

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

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

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

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

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

I agree, actually - I was quite surprised when I discovered this.  I
suppose I should bring it to the attention of the apr developers.

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

> > 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'?  Do you think it is a bug or a feature that it
uses the mtime?  Never mind whether the manpage mentions that it's the
mtime (it does, but only in passing, to explain the symlink case),
which do you think it _should_ use, for a desired feature of "find
files modified more recently than X"?

> 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.
-------------- 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/20060701/0f928712/attachment.pgp