Bug#376103: data loss is _always_ grave

[Peter Samuelson]

# 'important' is a compromise.  If you don't like it, appeal to the TC.
# Have a nice day.
severity important
tags 376103 upstream
forwarded 376103 dev at subversion.tigris.org
thanks

[Adam Borowski]
> You cannot assume that an important attribute like the timestamp
> won't ever change outside of your control.

Huh?  Who else will change it?  My admin surely had better not.  If
my working copy has write permissions for people I do not trust,
timestamps are the _least_ of my problems.  They can break my wc in
lots more interesting ways than that.


> It is an information to the _user_ that says "what was the last time
> when the file was modified".

That's your opinion.  The opinion of me and lots of people I know is
that it's also information to the _system_ that says "what was the last
time when this file was modified".  Most system tools do not care about
modification times, but the ones that do care almost always use the
mtime field.  That should tell you something.


> In fact, the Debian Policy, in section 4.6, requires (with a
> "should", and thus "important" clause) the timestamps to be preserved
> as far as reasonably possible.

Hogwash, section 4.7 (I assume you meant 4.7) says nothing of the sort.

     Maintainers should preserve the modification times of the upstream
     source files in a package, as far as is reasonably possible.

This has naught to do with subversion working copies.  It's all about
not changing file timestamps arbitrarily when you aren't changing
contents.

> Every single Unix tool obeys this, with three exceptions:
> * cp (due to historic reasons; fixable with -p)
> * scp (for compatibility with cp, also fixable)
> * subversion
  * sed -i
  * perl -i
  * shell redirects that overwrite a file
  * shell redirects that append to a file
  * emacs
  * rsync (also "fixable" with a flag)
  * patch
  * any other process I can think of that changes the contents of a
    file, except perhaps 'recode'

In fact, I think all the Unix tools you are talking about except recode
have one thing in common: when they set a file's mtime artificially, it
is to represent a file's contents being identical with those of a file
whose timestamp actually was the value they are using.  (Read that
sentence twice if it's confusing; I don't know a simpler way to put
it.)  To my knowledge, the only utility that decides that the change in
a file's contents should _not_ by default receive a timestamp update is
recode.

It's also worth mentioning that upstream's main response to this bug
report is "don't use broken tools like recode, then".


> 1. an user runs a script over his source tree (indent, s/\r//,
>    retabbing, etc)

Don't tell me your copy of 'indent' or 'sed -i' does not modify mtimes.
My copy surely does.


> Or, let's say, what about using an exotic, completely unsupported
> rare tool known as "tar"?

See above about file contents.  If you restore an archived file, either
it modifies both timestamp and contents, or neither.  (If you modified
the file since the tar backup, the restore will change both the
contents and the timestamp.  If you didn't modify the file since the
tar backup, the restore will change neither.)  In order to use tar to
break subversion, you have to back up a file in one place and restore
it to another, where both places coincidentally have not only the same
name but the same timestamp.  Given the resolution of file timestamps,
this seems highly artificial: chances are you're doing it on purpose.

> Bottom line:
> you can't drop data on the floor just because non-your metadata is
> not what you expect.  You can trust only what's in .svn (_your_ area).

So you believe web servers are also buggy when they rely on the mtime
to tell clients they already have the newest version of a file and
needn't bother downloading a refresh?

There are all kinds of Unix tools that rely, for proper functioning, on
the user not to lie to them.  Garbage in, garbage out.
-------------- 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/20060720/dbd5dddc/attachment.pgp