From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 777 invoked by alias); 1 Jan 2010 13:00:42 -0000 Received: (qmail 764 invoked by uid 22791); 1 Jan 2010 13:00:41 -0000 X-SWARE-Spam-Status: No, hits=-0.7 required=5.0 tests=AWL,BAYES_00,FH_DATE_PAST_20XX,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 01 Jan 2010 13:00:36 +0000 Received: (qmail 20322 invoked from network); 1 Jan 2010 13:00:35 -0000 Received: from unknown (HELO digraph.polyomino.org.uk) (joseph@127.0.0.2) by mail.codesourcery.com with ESMTPA; 1 Jan 2010 13:00:35 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.69) (envelope-from ) id 1NQh7J-0003QW-H8; Fri, 01 Jan 2010 13:00:33 +0000 Date: Fri, 01 Jan 2010 13:00:00 -0000 From: "Joseph S. Myers" To: Joel Brobecker cc: gdb@sourceware.org, binutils@sources.redhat.com Subject: Re: time to be serious about dropping CVS In-Reply-To: <20100101080137.GP2788@adacore.com> Message-ID: References: <20100101080137.GP2788@adacore.com> 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: 2010-01/txt/msg00011.txt.bz2 Since you sent this to the GDB and Binutils lists, I'll just repeat one point from my previous comments, which are all in the list archives. Do not try to plan a transition for the whole src repository. Try to plan one for GDB and Binutils together at most [*], on the basis that other projects such as Cygwin and Newlib should choose their own version control systems in their own way and at such times as are convenient to them. Thus you should operate on the basis that the shared toplevel files will always need merging between multiple repositories using multiple version control systems, simply because the various projects using them are independently run and should not be constrained to use a single system. My suggestion is to handle the shared toplevel files in a DVCS-pure way - no one master repository, changes committed to any repository get merged to the others automatically. But a separate master for them with all commits to them in the trunk of other repositories being rejected unless marked as merges from the master would be reasonable as well - as long as you don't constrain the repositories all to use the same VCS. [*] I leave open the question of whether Insight is considered part of GDB here - though making it a GDB branch rather than something present on the trunk might be a possibility with a VCS with better merging than CVS. I consider sim part of GDB here. I consider the cpu/ directory as part of binutils (necessarily, as the source code of some binutils files), but cgen/ as a separate project. I do not think there should be tcl/ and tk/ directories in the new GDB repository. -- Joseph S. Myers joseph@codesourcery.com