On 2007-03-27 10:39:22 +0200, Erik Huelsmann wrote:
> Backdating changing in itself is not a problem.
This is not what Ben Collins-Sussman said:
"We've had a policy (since the beginning) of not acknowledging tools
that change file contents without changing the timestamp. The 2 or 3
times we've discovered such tools, we've always shouted them down as
dangerous and broken, and they've been fixed. I don't see the latest
complaint as anything new."
(and when replying to this message, you didn't make any comment on
this point -- I assume you agree with Ben). So, if Subversion does
the same things, it is broken and dangerous. That's all.
> It just that 1 specific value isn't working out that great when the
> file hasn't changed in size. This almost never a problem, even if
> Vincent wants you to believe it is. There are a number of scenarios
> where it may lead to undetected changes in files. These scenarios
> are rare at best though.
They are rare in your opinion. I agree that most users won't be
affected. But you cannot know what some particular user will do.
And I recall that the user may lose some of his data. Even if this
is rare, I don't think any user will accept losing his data.
Subversion should take care of that, in one way or another.
> Vincent is frustrated with the fact that we don't want to listen to
You're completely wrong. I suggested the wontfix here only because
Subversion developers say that such a behaviour is "dangerous and
broken".
> him - at least, that's what I suppose he's feeling - whereas we've
> been rehashing all possibilities to improve the situation regarding
> the value we assign to mtime+file size in the past weeks (again!).
Note that I've never asked to consider the file size. I'm not even sure
that this is a good solution because it leads to inconsistent behavior.
Say, the user uses "recode" on a set of files, then does a "svn ci" and
sees that files are committed. He may then think that everything is OK,
but in fact, if some file size has not changed (I showed that this could
happen in real files), then this file has not been committed, and the
user may miss that.
Of course, in this case, the loss is probably not critical, but when
data integrity is concerned, what a developer should do is not "let's
implement this, and if we don't know any example that will lead to a
loss of data, that's fine", but "if I implement this, can I show that
it is not possible to lose data?".
> This discussion was entirely due to his persisted requests to
> reconsider the situation.
Note that in the first discussion, it was said that ctime was replaced
by mtime only because of Windows. That's why I asked it to be
reconsidered a few days ago.
> (So, you see, we think we are listening to him.) We've over and over
> come to the conclusion we can't do better than we currently do
> within the bounds of reasonable performance.
Your conclusion is wrong. First, making the heuristic choice optional
is a better solution: Windows and USB card users will still choose
the current behavior, while the other users could choose a much more
reliable solution (e.g. the mtime+inode solution, which should work
in more cases than ctime) without sacrificing performance. So, for
some users, the behavior won't change, and for other users, it will
be more reliable with the same performance. Globally, this would be
better.
Second, rsync, whose heuristic is also based on mtime, has an option
to ignore mtime (even if the behavior is slower, this is useful when
the user knows that there can be problems and/or before a change that
couldn't be reverted): --ignore-times. Similarly, the "make" command
has option -W (and "make clean" is a better solution if everything
needs to b rebuilt). I don't know any other software that is based
on mtime (AFAIK, backup software are based on ctime or read the
files, precisely because mtime is not reliable).
Third, Subversion's behavior is not documented (issue 2719).
> All of that isn't very much on topic, but I wanted to tell you where
> his comments might be coming from.
>
> Issue 1256 definitely isn't related to 2746 in the way that Vincent
> states. That's because it is about *recording* mtimes, not about
> restoring them
No, issue 1256 is about recording mtimes *and* restoring them.
Summary: Ability to preserve last modification time (mtime) of files
under version control
Sometimes it is useful to preserve creation/modification time of a
files under version control. File importing/adding/committing should
save these times together with all other file properties and checkout
of this file should restore these times instead of putting current
^^^^^^^
time. [...]
> - a script should easily be able to restore them though. [...]
If this is a script, that would definitely be the user's problem.
Thus that would be fine as far as Subversion is concerned.
--
Vincent Lefèvre <vincent_at_vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Mar 27 12:46:44 2007