On 3/23/07, Greg Hudson <ghudson@mit.edu> wrote:
> On Wed, 2007-03-21 at 21:49 +0100, Erik Huelsmann wrote:
> > Ben Reser tells me ctime updating can be turned off on many
> > filesystems and many admins seem to do so.
>
> That comment sounds confused. You can turn off atime updating for
> performance and many people do; there's no reason I know of to turn off
> ctime updating.
Yup. He told me that too, later.
> There does seem to be a real issue here:
>
> svn update
> mv file1 file2 # file1 has same size and mtime as file2
> svn rm file1
> svn st # file2 appears unchanged
> svn update # Smashes file2
>
> It may be an uncommon case, but there's no broken tool involved, and
> mv's behavior isn't going to change.
Right.
> I agree that all proposed solutions have serious drawbacks. Using ctime
> means working copies become slow after a filesystem backup, until
> cleanup is run.
Using ctime is not an option, since APR uses the creation time (aka
birth time) to fill the slot. I.e. on Windows, it's not a solution at
all since that time won't change after the initial creation. If they
were checked out together, it's likely creation times are equal.
> Using inodes means working copies become slow after a
> copy operation (even a well-executed one which preserves mtimes), until
> cleanup is run. Doing a full compare all the time means working copies
> are always slow.
Not all filesystems have inodes (fat). Linux 'creates' inodes for
these filesystems, but they are definitely not constant: I just
inserted my (fat formatted) USB stick and ran 'ls -i' on it. Removing
it, reinserting and 'ls -i' again: I got all different inode
numbers...
Also, the 'inode' number reported by APR on Windows is only guaranteed
as long as at least one process has the file open. After that, the
inode number may change again. Definitely *not* a number to be used by
a cache which may survive even reboots.
IOW, I agree it's a problem. Making update use full comparisons is a
one-liner. I think it's the only way to -portably- solve this problem.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 23 21:15:04 2007