From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12746 invoked from network); 29 Jun 1999 15:53:38 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 29 Jun 1999 15:53:38 -0000 Received: (qmail 10547 invoked by alias); 29 Jun 1999 15:53:26 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6930 Received: (qmail 10532 invoked from network); 29 Jun 1999 15:53:24 -0000 From: "Bart Schaefer" Message-Id: <990629155320.ZM21187@candle.brasslantern.com> Date: Tue, 29 Jun 1999 15:53:20 +0000 In-Reply-To: <19990629142840.A28884@caerdonn.eurocontrol.fr> Comments: In reply to Ollivier Robert "Re: public CVS archive" (Jun 29, 2:28pm) References: <199906281751.TAA17561@hydra.ifh.de> <000001bec210$8f5cee10$21c9ca95@mow.siemens.ru> <19990629142840.A28884@caerdonn.eurocontrol.fr> X-Mailer: Z-Mail (5.0.0 30July97) To: Zsh hackers list Subject: Re: public CVS archive MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Jun 29, 2:28pm, Ollivier Robert wrote: } Subject: Re: public CVS archive } } As long as you don't have a myriad of branches, CVS is fine. Having to } branches, one for 3.0.x and the other for 3.1.x is bearable. It makes } merging easier. Actually, in this particular case it makes merging more difficult. The directory structure has changed in 3.1.x (for example, all the zle_* files have moved to the Src/Zle subdir; in 3.0.x they're in Src) and bits and pieces of things have moved as well (for example, bin_fg() has moved from builtin.c to jobs.c, though both files are still in Src; other things have moved from builtin.c to files in new directory Src/Builtins). CVS is particularly poor at tracking entire file renames -- you have to remove the file from one directory and add it in another -- and doesn't help any more than any other source-code-control system when it comes to whole functions moved from one file to another. For many files, therefore, its extremely misleading to try to merge from 3.1.x<-->3.0.x using CVS's merge capability. Either you can't do it at all, or you end up with tracts of missing (in the 3.1-->3.0 direction) or duplicated (3.0-->3.1) code in some files. It just isn't worth it; it's easier to generate patches and then figure out which files to apply them to. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com