On Feb 25, 2005, at 10:38 AM, Steve Greenland wrote:
> On Thu, Feb 24, 2005 at 04:36:53PM -0500, Scott Palmer wrote:
>>> In previous discussions I argued that using modtimes as any
>>> indication
>>> of version is inherently unreliable and therefore useless.
>>
>> The reasoning is circular. We don't need to preserve the time in our
>> tool, because we can't rely on the time being preserved in some other
>> (broken) tool. That's precisely the problem we are trying to FIX.
>
> Scott, we've been through this before. File modification times are
> *unreliable* as an indicator of version. In particular, the fact
> that file X on system A has a modtime > file X on system B does not
> *reliably* indicate that A has a newer version than B. Because they are
> not reliable, I don't see the usefulness of maintaining them in VC *for
> the purpose of indicating version*.
I think we are generally in agreement here. My distinction is that I
generally use an exact match of the modification time to indicate that
files are the same - simply because there are people that I deal with
that work that way. They either don't have tools to do real file
compares, both files are not immediately available to a single person
to actually do the compare, or the people involved simply don't want to
learn that sort of thing. Those people are happy with timestamps and
I have to work with them. (I can tell them the timestamp over the
phone, in the absence of something more reliable, that's what happens.)
Perhaps some of me simply wants the problem of file times being
unreliable fixed, one tiny step at a time. There's no reason for
timestamps to be much less reliable than anything else, other than they
have been overlooked in various places.
I agree that something like merge tracking is much more important for
subversion in general. But thinking of the relative amount of effort
involved it seems the code to keep timestamps preserved could be
applied and done with, before the merge tracking problem could even be
explained. So my vote is to simply do it and put it behind us. I
personally would vote for merge tracking ahead of locking, I'm guessing
the locking was done sooner because a solution was possible sooner and
both items were on the to-do list. So let's get timestamp preservation
on the to-do list and let the development take its course. I'm
guessing it will happen before merge tracking, but not because it is
more important.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 25 17:42:33 2005