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

[Peter Samuelson]

[Vincent Lefevre]
> Note that upstream doesn't want to fix the bug:
> 
>   http://svn.haxx.se/dev/archive-2007-03/0734.shtml

More to the point, they've chosen a different fix, which is to also
store and look at file size.

See #376124 for the recode maintainer's reaction - he doesn't seem to
understand why changing the contents of a file then restoring the
timestamp to hide your tracks is a foolish thing to do by default.

I'm inclined to just wait until 1.5.0 is released upstream, with that
fix, and use that.  Upstream is right, as I said before:

| I find it hard to put into words just how broken I think this is, and
| I hope it's obvious enough that I don't have to.  You just _don't_
| modify files on a Unix filesystem and then hide the fact that you did
| so, unless the user has specifically indicated that there's a reason
| to do this - as with 'cp -p' or 'rsync -t' or 'touch -t'.  You don't
| make this the _default_ behavior!

My opinion hasn't changed.

> [1] This includes recode, mv, unzip, rsync and scp (possibly with
> options). The problem often occurs with recode, and even though it
> should be quite rare with other tools, it can still occur.

unzip, rsync and scp are poor examples.  They restore a file's
timestamp to a known value corresponding to a previous state of the
same file.  Think of it as a backup/restore operation.  And even so, of
those three, only unzip restores the timestamp by default.
-------------- 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/20070321/23caf8ea/attachment.pgp