Bug#376103: subversion: svn doesn't report modified file when
timestamp has not changed
Vincent Lefevre
vincent at vinc17.org
Fri Jun 30 09:21:53 UTC 2006
Package: subversion
Version: 1.3.2-3
Severity: grave
Justification: causes non-serious data loss
The "recode" utility does not update the timestamp (I assume this is a
feature). When a file is modified by recode, the commands "svn status"
and "svn diff" don't report any change, and "svn revert <file>" doesn't
do anything. This may lead to changes that won't be propagated and to
corrupted files (since revert doesn't work).
Looking at the timestamp (mtime) isn't sufficient to quickly decide
whether a file has been modified. Under Unix, the ctime should be
taken into account too (and/or possibly the inode). I think that the
ctime only should be safe, though it may sometimes be modified while
the file hasn't changed (e.g., due to a chmod). Note also that the
file size has changed after recode.
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (900, 'testing'), (900, 'stable'), (200, 'unstable')
Architecture: powerpc (ppc)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-20050829
Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1)
Versions of packages subversion depends on:
ii libapr0 2.0.55-4 the Apache Portable Runtime
ii libc6 2.3.6-15 GNU C Library: Shared libraries
ii libsvn0 1.3.2-3 shared libraries used by Subversio
ii patch 2.5.9-4 Apply a diff file to an original
subversion recommends no packages.
-- no debconf information
More information about the pkg-subversion-maintainers
mailing list