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

[Peter Samuelson]

[Vincent Lefevre]
> 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.

That is a point.


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

I never quite understood the timestamp manipulations of mbox files
either.  Something to do with being able to tell whether the user has
any new, unread mail - if atime > mtime, you have new mail, if mtime >
atime, you don't.  Or something like that.  It's a pretty atypical use
of these fields, though.

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

That's, again, a change to the working copy format.  Read your nearest
.svn/entries file some time and you'll see what I mean.  Actually don't
bother, that would give you the wrong idea, that you could just extend
the XML schema a bit.  In reality the XML is going away in 1.4.0.  (:

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

I did RTFM; you completely missed the point.  I don't know if you are
missing it on purpose, but you are still dodging my real question.
You're still saying "well it should use the mtime because the FM says
it uses the mtime".  But I'm not talking about the FM.  I'm talking
about what people actually use this tool for.  People actually use
'find -newer' to find files which are newer than some given file.
Given that, do you think that it makes sense for this tool to use the
mtime?

> Anyway the fact that "find" has deficiencies does not imply that
> Subversion is allowed to have ones too.

The reason I brought up find -newer was to ask, _again_, whether you
can think of any reason for the mtime field to exist at all, given that
you don't seem to think it should be interpreted to mean "time of the
file's last modification".  If it doesn't mean that, what in the world
does it mean, what is it useful for?  Do you see it as just a random
extra 32 bits of user-controlled metadata, to store extra app-specific
state on occasion, like with mboxes?

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

I'll discuss it again with upstream, bringing up the case of 'mv
wc_file_1 wc_file_2', but I have a feeling they're not going to want to
switch to ctime either, even on unix and netware.
-------------- 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/74bcb843/attachment.pgp