From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19591 invoked by alias); 20 Jun 2009 18:48:58 -0000 Received: (qmail 19571 invoked by uid 22791); 20 Jun 2009 18:48:57 -0000 X-Spam-Check-By: sourceware.org Received: from pool-98-110-183-121.bstnma.fios.verizon.net (HELO cgf.cx) (98.110.183.121) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 20 Jun 2009 18:48:48 +0000 Received: from ednor.cgf.cx (ednor.casa.cgf.cx [192.168.187.5]) by cgf.cx (Postfix) with ESMTP id F37163B0008; Sat, 20 Jun 2009 14:48:37 -0400 (EDT) Received: by ednor.cgf.cx (Postfix, from userid 201) id EA18A2B383; Sat, 20 Jun 2009 14:48:37 -0400 (EDT) Date: Sat, 20 Jun 2009 18:48:00 -0000 From: Christopher Faylor To: gdb@sourceware.org, "Joseph S. Myers" Subject: Re: What is keeping GDB in CVS ? Message-ID: <20090620184837.GA866@ednor.casa.cgf.cx> Mail-Followup-To: gdb@sourceware.org, "Joseph S. Myers" References: <87r5xgqk0k.wl%naesten@gmail.com> <20090619162308.GA13968@caradoc.them.org> <20090619162801.GA14773@caradoc.them.org> <20090619163753.GA9700@ednor.casa.cgf.cx> <20090619192236.GA10670@ednor.casa.cgf.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-06/txt/msg00205.txt.bz2 On Fri, Jun 19, 2009 at 07:29:18PM +0000, Joseph S. Myers wrote: >On Fri, 19 Jun 2009, Christopher Faylor wrote: >>So maybe they shouldn't be *shared*. There could be just one copy. I >>think everyone knows that you'll have problems as soon as you start >>duplicating data. This is no exception. >> >>I doubt that the gcc project would think it was a good idea but we >>could just break libiberty and the top-level configury into a separate >>repository too. Then when you make a change to a file, everyone gets >>the change and people will squawk immediately when you make a change to >>one of these files for gcc which happens to break a binutils build. > >That worked for the old GNU hardlinks-to-,v-files approach. I don't >think it's effectively supported by any version control system more >modern than CVS. You're reading more into what I wrote than I intended. I wasn't proposing any trickery. I'm just saying that, IMO, if a group of files is shared between projects the shared group of files should be stored in their own repository. I haven't used git so maybe it adds extra wrinkles but I can't see how it would be THAT hard to accommodate keeping things in separate directories. You can either use symlinks, or, 'source' lines in shell scripts and 'include' lines in Makefiles. I don't buy the complaining that this would cause terrible consequences for someone's established workflow. We're talking about programmers here. If they can't adapt to a change like this then it's hard to see how they could be contributing much to any of these projects. cgf