On 2/19/2007 12:22 PM, Les Mikesell wrote:
> Lukas Reck wrote:
>> 2007/2/19, Vincent Lefevre <vincent+svn@vinc17.org>:
>>> On 2007-02-19 06:28:21 +0100, Lukas Reck wrote:
>>> > So as I understand it, it is not exactly svn's fault, but recode
>>> > messing with mtime.
>>>
>>> It's both. But I'd say that it's more svn's fault since changing the
>>> mtime is not forbidden and there may be good reasons to change it.
>>> Only the ctime can't be changed by the user and can be regarded as
>>> reliable.
>>
>> So what is the rationale for not using max(mtime,cime) on POSIX(ish?)
>> systems instead of the mtime? And even if there is one, why is this
>> not documented?
>
> Ctime can never be less than mtime on anything resembling posix behavior.
That's not right, is it? What if I use touch to set the modification
time into the future? I see this on a Linux system:
$ touch -t 06010000 junk
$ ls -l junk
-rw-r--r-- 1 murdoch murdoch 3 Jun 1 2007 junk
$ ls -l --time=ctime junk
-rw-r--r-- 1 murdoch murdoch 3 Feb 19 13:04 junk
Does posix disallow this?
And a guess as to the rationale for this behaviour: svn uses mtime, so
that a user can mess with it in order to change svn's behaviour. If a
user does this accidentally (e.g. by using recode and not realizing that
it doesn't update mtime) that's bad, but if svn used ctime then the user
would not be able to control things.
I agree with whoever suggested that it would be nice to be able to tell
svn to use a stricter criterion, e.g. a full binary compare on each file.
Duncan Murdoch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Feb 19 19:12:30 2007