From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15909 invoked by alias); 21 Dec 2010 03:46:27 -0000 Received: (qmail 15893 invoked by uid 22791); 21 Dec 2010 03:46:25 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-qw0-f41.google.com (HELO mail-qw0-f41.google.com) (209.85.216.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 21 Dec 2010 03:46:20 +0000 Received: by qwa26 with SMTP id 26so3454946qwa.0 for ; Mon, 20 Dec 2010 19:46:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.232.211 with SMTP id jv19mr4257485qcb.207.1292903178438; Mon, 20 Dec 2010 19:46:18 -0800 (PST) Received: by 10.229.96.8 with HTTP; Mon, 20 Dec 2010 19:46:18 -0800 (PST) In-Reply-To: <20101221032725.GS2618@adacore.com> References: <20100101080137.GP2788@adacore.com> <20101221032725.GS2618@adacore.com> Date: Tue, 21 Dec 2010 03:46:00 -0000 Message-ID: Subject: Re: time to be serious about dropping CVS From: Jim Blandy To: Joel Brobecker , "Joseph S. Myers" , gdb@sourceware.org, binutils@sources.redhat.com Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes 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-12/txt/msg00062.txt.bz2 As one of the original designers of SVN, I really recommend switching to either git or Mercurial. It takes some getting used to, but any GDB hacker can handle that challenge. Once you switch, you will love the speed so much you'll cry when you have to use CVS (or SVN). Perhaps it would help to declare git usage questions from contributors "on topic" for the GDB lists, at least for a few months, so the developers familiar with the tools can help out the others. On 12/20/10, Joel Brobecker wrote: >> Just checking: is your task force still on target to have proposals by the >> >> end of the year? A report on progress would be good even if there aren't >> full proposals yet. > > I am a bit ashamed, but I have procrastinated :-(. I was introduced > a while ago to the "git cvsexportcommit" command, which effectively > allows me to work exclusively in git, thanks to our git mirror. > The only downsides at, the moment, are: The git mirror is only updated > every 30mins, and I need to do a CVS update before I push a commit > from git to CVS. On the other hand of the equation, we have a number > of hurdles to face before a conversion can be started, and the problem > is that the hurdles are not all just technical (multiple projects sharing > portions of the same repository), but human as well (convincing people > to change). > > So the balance of benefits versus effort made me give up a bit on > the idea, at least for now. For now, in order for this to happen, > we would have to change something in the way we either get the sources, > or in the way we build, or both. We might also not be able to do > the transition just on our own, and that means coordination with > other projects, etc. Perhaps, as more git features appear, we might > be able to find a simpler way to transition, and that could be > the trigger for transition to really start... > > One of the things that we could think about, is getting away from > our 'partial checkout' way of getting the sources. It's convenient, > but it is also makes us utterly dependent on CVS. I think there is > a simple solution to that: > (1) Separate out the projects that could go on to live their lives > on their own (Eg: expect, tcl, tck, winsup, rda, etc) > (2) And for the remaining projects, either: > (a) Share one large repository: We would have to change the way > we configure or the "make" command we use to build; > (b) Have our own set of sources, with synchronization issues > (which if effectively the same as (1), really). > Option (1) is not strictly necessary for option (2a), but I think > it would be a good cleanup, and probably benficial to those projects > too - as they would be getting more freedom, I think. I just realized > for instance that dejagnu is no longer part of src/. It's under git, > now. > > The problem is that you have to convince people that all these changes > are desirable, and that, I think, is more difficult than the technical > work itself... > > -- > Joel >