[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn status: does not notice changed file if timestamp of "new" file is older

From: Branko Čibej <brane_at_xbc.nu>
Date: 2002-11-13 01:52:38 CET

Philip Martin wrote:

>Philip Martin <philip@codematters.co.uk> writes:
>
>
>
>>I wonder if svn_io_file_affected_time() should simply return the mtime
>>on Windows? This may be the correct behavior on Unix as well, I'm not
>>sure the docstring's argument about tracking permissions is correct,
>>which bit of Subversion needs to know that they changed?
>>
>>
>
>Well, we don't appear to have any regression tests that rely on the
>ctime behaviour, on Unix they pass with this patch applied
>
>Index: subversion/libsvn_subr/io.c
>===================================================================
>--- subversion/libsvn_subr/io.c (revision 3763)
>+++ subversion/libsvn_subr/io.c (working copy)
>@@ -510,10 +510,7 @@
>
> SVN_ERR (svn_io_stat (&finfo, path, APR_FINFO_MIN, pool));
>
>- if (finfo.mtime > finfo.ctime)
>- *apr_time = finfo.mtime;
>- else
>- *apr_time = finfo.ctime;
>+ *apr_time = finfo.mtime;
>
> return SVN_NO_ERROR;
> }
>
My goodness, is that really what we had in the code?

>I don't think Subversion needs to know the ctime of a working copy
>file. The mtime is what is needed to track text changes, and property
>changes are tracked via the the mtime of the property file.
>
It's a common misconception that "ctime" means "creation time". It
doesn't. the ctime is the time of the last _change_ to the _inode_, and
as such doesn't bear any relation to Windows creation time. So yes, it's
totally wrong to rely on ctime, we should be looking only at mtime.

It's quite possible that APR gets this wrong, too.

    Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 13 01:53:28 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.