On 2/19/2007 1:29 PM, Lukas Reck wrote:
> 2007/2/19, Duncan Murdoch <murdoch@stats.uwo.ca>:
>> 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.
>
> svn only uses the mtime comparison as a shortcut to avoid doing a full
> binary compare on all files. I fail to see why users could need to
> control that behaviour.
Why would users want to modify a file but not change the mtime? Perhaps
they want some programs to treat the file as if it is unmodified. How
is svn to know whether it is one of those programs or not?
If they change a file's contents (and thus
> update the ctime), they normally want those changes to be commited.
And if they change the file's contents, they normally update the mtime.
We're talking about an abnormal case here, where a user has made a
choice to change a file but not to appear to have changed it.
> At
> worst, using ctime instead of mtime will result in doing some more
> binary compares.
Unless the user really did want svn to ignore the change, in which case
we'll get a commit that shouldn't have happened.
> Comparing the ctime would be more appropriate to determine if a file
> has been meddled with since the last update, wouldn't it?
Changing mtime is usually appropriate when meddling.
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:50:40 2007