From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32630 invoked by alias); 13 Oct 2011 21:51:06 -0000 Received: (qmail 32150 invoked by uid 22791); 13 Oct 2011 21:51:05 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 13 Oct 2011 21:50:38 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1RETAj-00064z-At from joseph_myers@mentor.com ; Thu, 13 Oct 2011 14:50:37 -0700 Received: from digraph.polyomino.org.uk ([172.16.63.104]) by EU1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Oct 2011 22:50:34 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.74) (envelope-from ) id 1RETAf-0007Z3-LY; Thu, 13 Oct 2011 21:50:33 +0000 Date: Thu, 13 Oct 2011 21:51:00 -0000 From: "Joseph S. Myers" To: Phil Muldoon cc: gdb@sourceware.org Subject: Re: GIT and CVS In-Reply-To: Message-ID: References: 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: 2011-10/txt/msg00084.txt.bz2 On Thu, 13 Oct 2011, Phil Muldoon wrote: > "Joseph S. Myers" writes: > > > On Thu, 13 Oct 2011, Phil Muldoon wrote: > > > >> So why are we still on CVS? I'm not a release manager, so I do not have > > > > Because the complications associated with having many projects in the same > > repository are a lot of work to disentangle, and it is a lot of work to do > > the conversion (including all the infrastructure scripts, user > > instructions etc.) for any one project. > > > > I think binutils+gdb is the right unit to aim for getting into a separate > > repository, as discussed in > > . > > Ok, thanks for your response. Beyond the reason why they were in the > same repository for how many years, why do they still have to be? > > I can understand that projects so closely involved need to be in > lock-step in their release objectives, but with healthy communities for > each project, do they need to be still? I've given my arguments many times before in past threads. In essence: * normal operations (checkouts, updates, tagging etc.) should be done in the normal way for the relevant version control systems, and the non-transparency of various systems for grafting pieces from different repositories tends to rule those out; * that a normal operation ("cvs update -d") doesn't work properly is one of the serious problems with the present system; * commits affecting both BFD and its clients are normal operations. So I think putting the BFD users together with BFD is right - but I think a separate master repository for the shared toplevel files is also right (with hooks in other repositories to check for attempts to commit changes to shared files - on the mainline - that aren't just merges from the separate master). The alternative for toplevel is the DVCSly pure approach with all repositories equal and no one master, but I think that would work less well in practice. > I think though, I am missing the point. If GDB decides, on its own, to > go with GIT, what happens to the other projects? What are the outcomes? Synchronizing BFD would be a great pain. For the projects other than binutils, I think they could continue just fine if gdb+binutils moves out (though with more toplevel pain if proper procedures aren't set up for keeping toplevel in sync). > I nearly decided to delete that line from the email as I did not want to > dilute the arguments. I wrote the ChangeLog parser for Eclipse as I found > ChangeLogs tiresome to write when history basically replaced it. I must > admit, even when I hack on emacs, it is still a pain. I'll continue to > do it, if people find it useful. However, git log is very, highly > configurable. The options are very broad. And, as you can generate a > git log from a local repository, the NFS thing should not be too > difficult to overcome? Even with local disk, git is much more I/O intensive. I timed looking at logs from a glibc checkout on local disk: $ time git log > /dev/null real 0m18.324s user 0m0.560s sys 0m0.304s $ time cat ChangeLog* > /dev/null real 0m0.314s user 0m0.000s sys 0m0.012s That's nearly 60 times slower. And apart from I/O cost the point remains that it is useful to have this information in tarballs and ad hoc snapshots, separated from the version control system and possibly imported into another. I'd be glad to *expand* ChangeLogs - add information about *why* changes were made to the existing *what* - and so make them more useful, but they are useful anyway. -- Joseph S. Myers joseph@codesourcery.com