From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27491 invoked by alias); 6 Oct 2009 16:11:23 -0000 Received: (qmail 27482 invoked by uid 22791); 6 Oct 2009 16:11:23 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 06 Oct 2009 16:11:19 +0000 Received: (qmail 14582 invoked from network); 6 Oct 2009 16:11:17 -0000 Received: from unknown (HELO digraph.polyomino.org.uk) (joseph@127.0.0.2) by mail.codesourcery.com with ESMTPA; 6 Oct 2009 16:11:17 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.69) (envelope-from ) id 1MvCdA-0005ME-0R; Tue, 06 Oct 2009 16:11:16 +0000 Date: Tue, 06 Oct 2009 16:11:00 -0000 From: "Joseph S. Myers" To: Jim Meyering cc: "H.J. Lu" , Tom Tromey , GDB Subject: Re: gdb.git mirror is broken In-Reply-To: <87d4504mnl.fsf@meyering.net> Message-ID: References: <6dc9ffc80910051730p207a14f2m5ee6ff560ea60c33@mail.gmail.com> <87ws397z1b.fsf@meyering.net> <6dc9ffc80910060608u60ccf9eal72ab51f216b7f75c@mail.gmail.com> <87ocok4nvz.fsf@meyering.net> <87d4504mnl.fsf@meyering.net> 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-10/txt/msg00105.txt.bz2 On Tue, 6 Oct 2009, Jim Meyering wrote: > No pressure from me. > I barely have time to help with the technical side of things, > so if you want someone willing to invest in advocacy I'm not your man. I don't want advocacy, but *technical design*. Technical design based around showing how common tasks translate to a proposed new system, existing scripts are converted and common errors are made harder. Technical design that demonstrates that the usual tasks for people making occasional changes are at least as easy and intuitive as now. Technical design that shows how the breakage that is the subject of the present thread will not be possible in the proposed system. (No doubt it will also make additional things possible for version control experts, but the people proposing designs need to think in normal user terms.) Personally I think a single repository for GDB and binutils together, with configure options for building only one or the other, might be a reasonable approach (with other projects left to move from CVS or not at their own choice and in their own time), but that's not the level of design needed here; it doesn't even address how to handle gdbtk. For shared toplevel files, libiberty etc., I think it would be reasonable to do things in a DVCSly pure way and have no master repository and scripts automatically merging commits from one repository to another (possibly using a different version control system), or to declare GCC the master for all files present there and disallow non-automatic commits to the shared files on the mainline of other repositories. But a detailed design would need to demonstrate such scripts working in practice. -- Joseph S. Myers joseph@codesourcery.com