Re: Timestamp race avoidance in do_update()

[Laine Stump]

address@hidden (Larry Jones) writes:

> Laine Stump writes:
> > 
> > What I'm wondering is if we could change the "sleep(1); to be a
> > usleep(200) in a while loop instead. This should trim 1/2 a second
> > from each invocation of commit, on average, which can be quite a lot
> > when you're talking about several thousand files with dozens of
> > revisions for each...
> 
> Unfortunately, usleep() isn't portable.

Okay, then how about nanosleep()? Here's what the nanosleep() manpage
on NetBSD says about its portability:

  The nanosleep() function conforms to IEEE Std 1003.1b-1993 (``POSIX'').

(This is "Realtime Extensions to Posix"). (The only standard that
applies to usleep() is "X/Open Portability Guide Issue 4 Version 2
(XPG4.2), which doesn't sound nearly as impressive as something with
POSIX in the name).

Note that Windows doesn't even have sleep(). The "glue" stuff in the
windowsNT directory implements a sleep(n) function which is a call to
the Windows API Sleep(n*1000). (No, I don't know what the Honeywell
Level 6 OS provides, or VMS or whatever. Unfortunately, the only
machines I have access to these days are NetBSD, Linux, and Windoze).

>  Like I keep saying, the trick
> (if you want to call it that) is to commit those several thousand files
> with a single invocation of commit so you only pay the price once
> instead of over and over and over.

That would make for a *much* more complex and memory-intensive perl
script (the script in question being one which converts VSS history to
CVS history).

Aside from the basic extra duty of keeping track of multiple files at
once rather than cycling through a list, each commit for each file has
a different log comment, so multiple commits *can't* be done with a
single invocation of cvs. (I take that back - I suppose I could save
all log comments, then go back and change them later with a long
string of "cvs admin -m<rev>:<message> <file>" commands, but that
makes the script even more complex and memory intensive, and we must
remember that I'm a lazy programmer, who would rather change one sleep
to nanosleep() than to write a ton of confusing perl ;-)