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

[Peter Samuelson]

[François Pinard]
> I quite object to the principle that Subversion limitations may be
> turned into Recode bugs, and even go as far as being considered
> "grave".

The severity 'grave' may or may not be correct - when redirecting the
bug report to 'recode', I simply left it at the severity it was
originally reported.

But I did _not_ reassign the bug because of "Subversion limitations".
I'm _not_ just trying to find a scapegoat.  I reassigned it because I
believe it's _wrong_ to change a file's contents and hide this fact by
restoring the original timestamp.  (I mean, that's a bad default; an
_option_ to do this is of course often desirable.)

From the recode documentation:

    the time-stamps associated with files are preserved, to reflect the
    fact that changing the code of a file does not really alter its
    informational contents.

Automated processes, though, don't care about "informational contents",
they care about actual bits and bytes.  While it's true that the
'modification time' of a file is sometimes used merely as information
for humans, there are also quite a few instances where it is used by
automated processes.  Whether it's a backup script that only picks
files modified since the last backup was done, or a web server that
sends a 304 response to a client ("you already have the latest version
of this file"), or an rsync process deciding which files to
resynchronize with a remote server, all of these uses will do the Wrong
Thing if you do what recode does by default.

I believe it is reasonable for a program to assume that if a file's
modification time hasn't changed, the file's contents also haven't
changed.  This is why we have a modification time field at all.
Violating this assumption as a default mode of operation is wrong.

> Changing Recode default in this area would mean that people who recode 
> after unpacking would have to use a new option

Why would they have to do this?  Why would users either assume or
desire that after running recode on their files, that the files will
have their old timestamps?

I'm genuinely curious, because for all the uses of a timestamp that I
can think of, the more correct behavior depends on it reflecting the
actual time of last modification.

> I do not have (nor want) the full history of the report above, but in
> the dark, I'm tempted to guess it came out the frustration of someone
> who once used Recode without reading its documentation.

Quite so.  I still think recode does the wrong thing by default, but
the bug report did apparently come from someone who didn't know that
recode's behavior is on purpose.
-------------- 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/20060715/196b8970/attachment.pgp