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