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. If they change a file's contents (and thus
update the ctime), they normally want those changes to be commited. At
worst, using ctime instead of mtime will result in doing some more
binary compares.
Comparing the ctime would be more appropriate to determine if a file
has been meddled with since the last update, wouldn't it?
--
Lukas Reck
---------------------------------------------------------------------
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:29:42 2007