severity 376103 grave
thanks
This is a _data loss_ bug. And thus, it cannot have any severity
other than "grave", end of story.
You cannot assume that an important attribute like the timestamp
won't ever change outside of your control. It is an information to
the _user_ that says "what was the last time when the file was
modified". 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.
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
I tried to work around that severity="important" bug (by using a
wrapper over svn), but unfortunately the wrapper had a minor bug that
made it overzealous in restoring timestamps. And yet, instead of
losing just the timestamps, #376103 made me lost the whole revision.
Today, you can blame this loss on my fault -- but what about this:
1. an user runs a script over his source tree (indent, s/\r//,
retabbing, etc)
2. now, you have two different versions of a file with the same mtime
3. one of the versions is copied over the other using any non-buggy
Unix tool
4. subversion is run...
Where's the user's fault in this scenario?
Or, let's say, what about using an exotic, completely unsupported
rare tool known as "tar"?
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).
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
