Duncan Murdoch wrote:
>>> 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?
Yes, I said it wrong. Ctime can never be older than the time mtime was
last changed (because changing mtime is an inode change that will result
in ctime being updated to the current time). I didn't consider the case
where the value of mtime was artificially set in the future, but that
doesn't affect the case here where something is setting mtime back to
its prior value after a change.
> 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.
If that was the intent, it doesn't see to have satisfied anyone. I don't
see any arguments here suggesting that this undocumented behavior is a
good thing. CVS didn't have any equivalent mechanism and I can't recall
anyone ever wanting a way to tell it to pretend a modified file wasn't
modified in a decade of use.
> 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.
Yes, or make that the default with a way to tell it to do the
optimization based on timestamps.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Feb 19 20:37:09 2007