From owner-cvs-all Wed Aug 23 10:54:10 2000 Delivered-To: cvs-all@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id EDCE937B422; Wed, 23 Aug 2000 10:54:01 -0700 (PDT) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id LAA08389; Wed, 23 Aug 2000 11:53:55 -0600 (MDT) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id LAA13118; Wed, 23 Aug 2000 11:52:38 -0600 (MDT) (envelope-from nate) Date: Wed, 23 Aug 2000 11:52:38 -0600 (MDT) Message-Id: <200008231752.LAA13118@nomad.yogotech.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Josef Karthauser Cc: Nate Williams , Warner Losh , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/games/fortune/datfiles fortunes In-Reply-To: <20000823184845.D13773@pavilion.net> References: <20000814003636.A74639@pavilion.net> <200008140753.AAA08038@netplex.com.au> <20000819124824.E88550@lucifer.bart.nl> <20000822161835.B807@dragon.nuxi.com> <20000823091714.D650@pavilion.net> <200008231648.KAA02382@billy-club.village.org> <200008231704.LAA02617@billy-club.village.org> <200008231707.LAA12343@nomad.yogotech.com> <20000823184240.B13773@pavilion.net> <200008231743.LAA13050@nomad.yogotech.com> <20000823184845.D13773@pavilion.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > If we have "utime/user" we probably don't. Utime (by which I mean > > > any format with a resolution of a second) on it's own probably isn't > > > sufficient without a lock and a sub increment counter (although a byte > > > from /dev/urandom may work..... only joking! :) > > > > Actually, given the updates from CVS, I think a utime counter is quite > > adequate. I don't think we're pushing multiple updates/sec at this > > point. > > Multiple updates/sec no - but can you guarantee that in any given second > there won't be two commits. If you can't then we should use an increment > counter, or not bother (Or am I being too exacting here?). Sorry, I meant multiple commits/sec. I think if there are multiple commits/sec, the chance of someone getting some of them and not all of them is almost nil, and given the fact that CVS doesn't keep this from happening (we have no locking), I don't think it's a problem we should concern ourselves with. If/when it becomes a problem, CVS will need some sort of locking protocol, and we can update the file in the middle of the lock. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message