(no subject)

[root]

>From address@hidden  Tue Feb 13 07:55:33 2001
>Return-Path: <address@hidden>
Received: from fencepost.gnu.org (fencepost.gnu.org [199.232.76.164])
        by gateway.camelot.jp (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id 
HAA05813
        for <address@hidden>; Tue, 13 Feb 2001 07:55:31 +0900
Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org)
        by fencepost.gnu.org with esmtp (Exim 3.16 #1 (Debian))
        id 14SRrE-0007Jc-00; Mon, 12 Feb 2001 17:54:08 -0500
Received: from merc94.us.sas.com ([149.173.6.4])
        by fencepost.gnu.org with esmtp (Exim 3.16 #1 (Debian))
        id 14SRq2-0007Gt-00
        for <address@hidden>; Mon, 12 Feb 2001 17:52:54 -0500
Received: from merc94.us.sas.com ([127.0.0.1]) by merc94.us.sas.com with SMTP 
(Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
        id CT5ZZ28L; Mon, 12 Feb 2001 17:52:50 -0500
Received: from 10.28.149.26 by merc94.us.sas.com (InterScan E-Mail VirusWall 
NT); Mon, 12 Feb 2001 17:52:50 -0500 (Eastern Standard Time)
Received: from concours.pc.sas.com (concours.pc.sas.com [10.26.2.63])
        by mozart.unx.sas.com (8.9.3 (PHNE_18979)/8.9.3) with ESMTP id RAA27110;
        Mon, 12 Feb 2001 17:52:49 -0500 (EST)
Received: (from address@hidden)
        by concours.pc.sas.com (8.9.3/8.9.3) id RAA30323;
        Mon, 12 Feb 2001 17:52:48 -0500 (EST)
        (envelope-from sasblc)
From: Brad Chisholm <address@hidden>
To: Larry Jones <address@hidden>
Cc: address@hidden, address@hidden
Subject: Timestamp race avoidance in do_update()
Message-ID: <address@hidden>
References: <address@hidden> <address@hidden>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mutt 1.0.1i
In-Reply-To: <address@hidden>; from address@hidden on Mon, Jun 05, 2000 at 
03:40:57PM -0400
Sender: address@hidden
Errors-To: address@hidden
X-BeenThere: address@hidden
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:address@hidden>
List-Post: <mailto:address@hidden>
List-Subscribe: <http://mail.gnu.org/mailman/listinfo/info-cvs>,
        <mailto:address@hidden>
List-Id: Announcements and discussions for the CVS version control system 
<info-cvs.gnu.org>
List-Unsubscribe: <http://mail.gnu.org/mailman/listinfo/info-cvs>,
        <mailto:address@hidden>
List-Archive: <http://mail.gnu.org/pipermail/info-cvs/>
Date: Mon, 12 Feb 2001 17:52:48 -0500
Status: O
Content-Length: 2767
Lines: 68

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!

-Brad


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

_______________________________________________
Info-cvs mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/info-cvs