Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 88162 invoked by uid 500); 5 Feb 2001 19:18:48 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 88084 invoked from network); 5 Feb 2001 19:18:41 -0000 Date: Mon, 5 Feb 2001 11:22:26 -0800 (PST) From: rbb@covalent.net X-Sender: rbb@koj To: new-httpd@apache.org, jim@jaguNET.com Subject: Re: Release Strategy In-Reply-To: <200102051913.OAA21574@devsys.jaguNET.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N > > why does the tree ever have to be "frozen", even for ten minutes? > > as long as you're doing a "cvs tag" of a checkout and not a "cvs > > rtag -r HEAD", you'll never collide with checkins that happen after > > you've done your checkout but before you've tagged. they'll just > > end up being part of the next tag&roll. no big deal when that > > happens on a reliable schedule. > > It's not collisions, I think, but the fact that whoever is tagging > has knowledge of the exact state of the tree... And to prevent > weird things with multi-commit patches. More preventative than > anything else I would think. My only reason for suggesting a 10 minute freeze, was for prevention. I want to be 100% sure that we aren't going to have to fix a CVS tree. If we can garauntee that we won't have any problems, then we can forget about the 10 minute freeze. Since I will be doing the tagging from a cron-job, I fully suspect that the freeze would actually be about a minute and a half. Ryan _______________________________________________________________________________ Ryan Bloom rbb@apache.org 406 29th St. San Francisco, CA 94131 -------------------------------------------------------------------------------