From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8937 invoked by alias); 13 Oct 2011 23:03:18 -0000 Received: (qmail 8918 invoked by uid 22791); 13 Oct 2011 23:03:16 -0000 X-SWARE-Spam-Status: No, hits=-6.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 13 Oct 2011 23:02:55 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p9DN2m67011015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Oct 2011 19:02:48 -0400 Received: from localhost.localdomain (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p9DN2kHx021916; Thu, 13 Oct 2011 19:02:47 -0400 From: Phil Muldoon To: ams@gnu.org Cc: joseph@codesourcery.com, gdb@sourceware.org Subject: Re: GIT and CVS References: Reply-to: pmuldoon@redhat.com X-URL: http://www.redhat.com Date: Thu, 13 Oct 2011 23:03:00 -0000 In-Reply-To: (Alfred M. Szmidt's message of "Thu, 13 Oct 2011 17:43:20 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2011-10/txt/msg00095.txt.bz2 ams@gnu.org (Alfred M. Szmidt) writes: > >> 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? > > Joseph mentioned other reasons as well, it isn't just because they > have been in a single tree for many years. One other thing worth > mentioning is that unified source builds are immensly useful. I'm not debating that a unified source is useful, of course it is. I personally build GDB on Fedora, and beyond what is in the tree, there are many non-inclusive packages I have to find to build GDB. Are your experiences different on your build setup? What do you have to include in your build environment, beyond what is included? I am genuinely interested from a cross-building experiences on many/disparate platforms? > > I hack on GDB, and I really don't hack on much else. This is not > to diminish other projects, I just don't hack on them. While other > modules represented by other projects are important, I am trying to > understand the reason why this is a blocker? Building GDB requires > a lot of dependencies outside of what is provided in the > repository. > > GDB only requires a normal POSIX system to compile. I don't deny that. But this is the difference between what is included in the repository, which seems to be the thrust of the argument, over which is included in pretty much every distro out there. Given an X distro system, can you build GDB without any other external dependencies? I think not. If other dependencies can be managed externally, why cannot other internal dependencies? > > ChangeLogs are very useful whatever the version control system; > > it's routine to import snapshots from one system into another and > > the ChangeLogs are readily available to see what source version > > you actually have there. ChangeLogs are convenient to grep and > > much less I/O intensive than git operations are (especially when > > your checkout is on NFS). > > You can also fix ChangeLog entries after the fact, which is not > possible with git's commit messages. > > 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? > > Could you explain how `git log' replaces ChangeLog? It doesn't do much > more than what `cvs log' does, so you still need to write which > function/variable was modified, and git log doesn't do that as far as > I know (it only lists which files, and how many lines where > added/delete which isn't very useful). Jan has covered this in detail. Lets just divorce this argument for now. If we have to continue building ChangeLogs with GIT then so be it. I'm not against this. Cheers, Phil