On 3/21/07, Alan Barrett <apb@cequrux.com> wrote:
> On Wed, 21 Mar 2007, Vincent Lefevre wrote:
> > I'm not asking to choose between performance and support for some
> > (non always broken) tools. Using ctime (possibly in addition to
> > mtime[*]) should be fine.
> >
> > [*] that would take a few additonal processor cycles per file, so that
> > the user won't see the speed difference.
>
> If the underlying file system has file IDs (such as inode numbers on
> unix-like systems), then you can also check whether the file ID has
> changed. On unix-like systems, a single stat() call will give you
> ctime, mtime, size, inode number, and several other fields. I'd check
> them in this order: mtime, size, inode (if available), ctime (only if
> inode is not available). I see no point in checking the ctime if inode
> numbers are available, because the action of replacing a file with
> another file (such as via the "mv" command on unix-like systems) will
> always change the inode number, but will not necessarily change the
> ctime.
Encoding inode numbers in a working copy doesn't work exactly great,
since working copies are allowed to move from one system to another.
When doing so, this would invalidate the entire working copy inode
cache.
Ben Reser tells me ctime updating can be turned off on many
filesystems and many admins seem to do so. Next to that, it doesn't
exist on Windows, nor does it exist in some (many?) Mac filesystems
UFS and HFS don't know the concept.
In order to create a ctime value in Windows, the APR developers took
the 'Creation time' to fill the slot. This means the value won't
change - ever - after file creation.
So, to be short, the system you are proposing works on some OSes, but
many (probably the majority) of our users won't benefit from a change
like that.
Not to be mean, but did you actually ever run into this problem
yourself, or are we just arguing for the sake of argument? Because I'm
still not denying it *may* happen, but chances are too slim to meet
the problem more than once in your lifetime, unless you have a real
use-case.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 21 21:49:50 2007