From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14124 invoked from network); 2 Apr 2000 00:44:42 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 2 Apr 2000 00:44:42 -0000 Received: (qmail 21279 invoked by alias); 2 Apr 2000 00:44:33 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 10378 Received: (qmail 21261 invoked from network); 2 Apr 2000 00:44:32 -0000 From: "Bart Schaefer" Message-Id: <1000402004426.ZM17561@candle.brasslantern.com> Date: Sun, 2 Apr 2000 00:44:26 +0000 In-Reply-To: Comments: In reply to Peter Stephenson "Re: sourceforge.net CVS tree ready for use" (Apr 1, 9:51pm) References: X-Mailer: Z-Mail (5.0.0 30July97) To: zsh workers mailing list Subject: Re: sourceforge.net CVS tree ready for use MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Apr 1, 9:51pm, Peter Stephenson wrote: } Subject: Re: sourceforge.net CVS tree ready for use } } One question is whether we commit CVS changes straight away, i.e. when } the patch is posted to the list, or wait for comments. The latter will } be a little messy, since other developers would have to apply the } patch to try it, then remove it to avoid CVS reporting a conflict. CVS will only report a conflict if the checked-in version differs from the patched version. Otherwise it'll just say "... already contains the changes ...". The most likely source of actual conflicts would be when some patches have been applied from the list but aren't yet in the CVS repository, or the reverse. } We should certainly think about Andrej's suggestion that the patches } can be moved offlist now we have a regular repository. As we have } write permission on sourceforge, a way for doing that over the net } could probably be handled. Or maybe Geoff can think of something he } can set up. A shortcoming of CVS is that there's no reasonable way to generate a patch from it without either (a) tagging both before and after every commit (and the before-tag also had better be after updating, or you create overlapping patches), or (b) generating the patch by diffing against the modified sandbox before committing. Of course, only the developer who actually made the changes can do (b); if he wants anyone else to be able to regenerate his patch, he has to do (a). -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com