Your message dated Sat, 15 Jul 2006 12:25:41 +0200 (CEST)
with message-id <[EMAIL PROTECTED]>
and subject line recode: bad default: hides file modifications by restoring
mtimes
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
On Fri, 14 Jul 2006, François Pinard wrote:
> [...]
> Hi, Peter, Santiago, Guilherme and others.
>
> I quite object to the principle that Subversion limitations may be turned into
> Recode bugs, and even go as far as being considered "grave".
> For me, it is reminiscent of the times when some CVS fanatics were filing bugs
> against packages everywhere for not being "harmonious" to CVS, and rather
> demonstrating to many a few persistent CVS drawbacks and pitfalls. My
> position then was that CVS users should learn to live with their choice,
> instead of pushing their pain all around.
>
> Now, this being said, I find Subversion quite sympathetic, and even felt like
> complying for a few jiffies. Why does Recode restore the time stamp for the
> file it overwrites? I merely copied the behaviour of Rahul Dhesi's programs,
> who made many admirable tools. Moreover, a sane Makefile never overwrites a
> dependency anyway, so the choice had no real impact on average. Massive
> recoding is often done on a Unix distribution which is unpacked on Windows, or
> vice-versa, and for many distributions, the time stamp relationship between
> files ought to be carefully preserved, so to avoid spurious remaking of files
> on the user side, as the user does not always have all maintainer tools
> installed.
>
> Changing Recode default in this area would mean that people who recode after
> unpacking would have to use a new option, merely so Subversion users do not
> have to use one. If for favoring Subversion users, I choose to impact other
> users, they could rightly complain as well.
>
> May I suggest that Subversion users learn to do ``recode -t``? That
> is rather easy. 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.
I think this qualifies as a complete explanation why this is not to be
considered as a bug in recode, so I'm closing this report (the one in recode).
Thanks a lot.
--- End Message ---
