> Well, heck, that's the bogosity right there. Is that normal on win32?
> When you copy a file, the timestamp doesn't change?? I've never heard
> of such a thing.
This is normal on Win32. It's useful behavior in a lot of situations,
but really inconvenient in others. Note that this is usually referred to
as the "Modified Date" on Windows.
> Right. The first check we make is whether the timestamp has changed.
> If the timestamp hasn't changed, svn assumes it couldn't *possibly* be
> modified. (If the timestamp has changed, then svn resorts to
> file-size and possibly brute-force.) This is exactly what CVS does as
> well.
Timestamp may remain the same and may even go backwards (if I copy an older
version
of the file over a newer version).
> So what's going on here is an odd copy behavior on win32, which
> doesn't match unix behavior. What's the right solution?
The simplest thing is to always brute-force. More rational would
be to always check timestamp AND file size. The edge cases that aren't
caught
by the combination will be few and far between.
The 'right thing' would be to register for file change notifications raised
by the OS, but
this is platform-specific (possibly file system-specific) and complicated.
John C Barstow
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 12 21:27:15 2002