From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6182 invoked by alias); 19 Jun 2009 17:30:48 -0000 Received: (qmail 6160 invoked by uid 22791); 19 Jun 2009 17:30:44 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_83,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 19 Jun 2009 17:30:36 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n5JHUXAr025622; Fri, 19 Jun 2009 13:30:33 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n5JHUW1O018328; Fri, 19 Jun 2009 13:30:33 -0400 Received: from opsy.redhat.com (vpn-12-208.rdu.redhat.com [10.11.12.208]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n5JHUVNP007272; Fri, 19 Jun 2009 13:30:32 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id AE938486CC; Fri, 19 Jun 2009 11:30:30 -0600 (MDT) To: gdb@sourceware.org Cc: Samuel Bronson Subject: Re: What is keeping GDB in CVS ? References: <87r5xgqk0k.wl%naesten@gmail.com> <20090619162308.GA13968@caradoc.them.org> <20090619162801.GA14773@caradoc.them.org> <20090619163753.GA9700@ednor.casa.cgf.cx> <20090619164943.GA16137@caradoc.them.org> From: Tom Tromey Reply-To: tromey@redhat.com Date: Fri, 19 Jun 2009 17:30:00 -0000 In-Reply-To: <20090619164943.GA16137@caradoc.them.org> (Daniel Jacobowitz's message of "Fri\, 19 Jun 2009 12\:49\:43 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00201.txt.bz2 >>>>> "Daniel" == Daniel Jacobowitz writes: Daniel> The solution I'd like best, I think, is one with separate projects Daniel> that makes it easy to manually or automatically sync revisions from Daniel> the shared directories. This may be nothing more than some clever Daniel> push hooks, for instance to reject manual changes to bfd/ being pushed Daniel> to the central gdb repository and to automatically propogate changes Daniel> to bfd/ from binutils. Anyone feeling inspired enough to build a Daniel> proof-of-concept? I meant to reply again on the binutils thread, but I'm super distracted these days. I researched it a bit and I believe that git doesn't provide a nice way to solve the modules problem. There are a couple promising approaches but I think if you look closely they don't really work (in one case the exact feature we need was never merged into git). One idea I had is to have an "infrastructure" repository holding top-level configure, plus libiberty and include. Then, gcc, src, cgen, cygwin, etc would simply merge from this repository. And, we'd have a rule: no local changes. These kinds of merges are trivial, we do them all the time in archer (archer's master branch tracks gdb's master branch this way). You could even automate them, if the no local change rule was enforced. Finally, I think binutils+gdb should probably just be a single source repository. They share enough to warrant that, IMO. I suspect the disk space overhead is not large. I have no idea what to do about insight. The problem with this approach is that it is less convenient than what we have now. If you have a change that touches libiberty then you need two separate commits. I suppose this is basically what you're saying :-) I guess some new version of svn solves the module problem. But... after working with git for the last year, I used svn for a gcc patch this week and I was surprised by how amazingly slow it now feels. I'd really prefer git by a large margin. Tom