Greg Hudson wrote:
> On Mon, 2005-06-27 at 10:48 -0500, Carl Karsten wrote:
>
>>Fill me (and perhaps Erik) in - What is the use case for a script that would be
>>impacted by this bug?
>
>
> svn update
> <make a scripted change to a file>
> svn commit
>
> If the scripted change occurs before the system time advances past the
> FAT resolution, Subversion might not detect that the file has changed,
> and the commit won't transmit that file.
Yup. I was only considering the local file vs time stamp on server.
>
> (We could store the size of the unmodified working copy file
> in .svn/entries, and check whether that has changed as well. That would
> substantially reduce the impact of this kind of bug. But I'm not sure
> it's worth the effort and space and code complexity.)
Size isn't good, that will miss a change that doesn't add/remove - like bumping a
version number, something I can see a script doing.
Now I understand the sleep concept. I was thinking it would be better to back up
the time to the previous meaningful time, but then all files will be seen as
different, not just ones that were modified within the 2 second window.
Someone suggested touching a file two times and checking the difference - that is
icky. If there isn't an OS call to figure out what it is, I think it is better to
use fat as the worst and sleep 2 unless overridden by a switch or config setting
somewhere.
Carl K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 27 20:12:55 2005