[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Timestamp race avoidance in do_update()

From: Brad Chisholm
Subject: Timestamp race avoidance in do_update()
Date: Mon, 12 Feb 2001 17:52:48 -0500

One of our groups here is implementing their own CVS client, which
communicates to a standard CVS server using the client/server
protocol.  They have been seeing slowdowns in processing multiple
files due to the sleep(1) in do_update().  In searching the archives
for an explanation of this code, I came across the following thread
(see below).

Just to make sure I understand, CVS is sleeping to ensure that any post-CVS
process which might modify the file must also change the timestamp.  This
is necessary, because the CVS client relies on the timestamp to determine
whether a file has been modified.  (i.e. if the current timestamp of the
file matches the timestamp stored in the Entries file, then the client
will consider the file unchanged, even if the contents have actually changed).

Thus, without this code, the following scenario could be problematic:

   cvs checkout file.txt
   echo "Appending to file" >> file.txt
   cvs commit -m 'testing' file.txt

If the checkout and the modification to the file happen in the same second,
CVS will believe the file is unmodified, so the commit will not actually
do anything.

Is this a correct assessment?  Are there other reasons? 

Thanks for any enlightenment!


On Mon, Jun 05, 2000 at 03:40:57PM -0400, Larry Jones wrote:
> address@hidden writes [using very long lines]:
> > 
> > One more question though.... when I do an update... I get the response
> > quite quickly - but then between the end of the "update" content, and
> > the "ok", there appears to be a pause of about 1 second. This seems to
> > be much longer than i would expect, is there any particular reason for
> > this?
> Yes, and no.  It's part of the "timestamp race avoidance" code --
> whenever CVS creates or updates files, it sleeps for one second before
> returning to ensure that no subsequent process can change the file
> without also changing its timestamp.  When the standard CVS client does
> an update, it sends all the directory and file information and then does
> one update, so there's only one sleep; you're sending an update for each
> file, so you're paying a much higher price than you should be.  You
> should probably change your client to work more like the standard CVS
> client.
> That's the "yes" part; the "no" part is that it appears that in
> client/server CVS, the client and the server *both* sleep; I can't see
> any reason for the server to sleep if the client is going to, so perhaps
> that should be changed.
> -Larry Jones
> My brain is trying to kill me. -- Calvin

Brad L. Chisholm      SAS Institute, Inc.      address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]