From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4760 invoked by alias); 11 Dec 2002 03:44:57 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 4753 invoked from network); 11 Dec 2002 03:44:56 -0000 Received: from unknown (HELO pizda.ninka.net) (216.101.162.242) by sources.redhat.com with SMTP; 11 Dec 2002 03:44:56 -0000 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id TAA03572; Tue, 10 Dec 2002 19:41:05 -0800 Date: Tue, 10 Dec 2002 19:57:00 -0000 Message-Id: <20021210.194105.61848558.davem@redhat.com> To: mark@mark.mielke.cc Cc: zack@codesourcery.com, jsm28@cam.ac.uk, wlandry@ucsd.edu, gcc@gcc.gnu.org Subject: Re: source mgt. requirements solicitation From: "David S. Miller" In-Reply-To: <20021211034224.GA20375@mark.mielke.cc> References: <87isy2mj1y.fsf@egil.codesourcery.com> <20021211034224.GA20375@mark.mielke.cc> X-FalunGong: Information control. Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-12/txt/msg00570.txt.bz2 From: Mark Mielke Date: Tue, 10 Dec 2002 22:42:24 -0500 On Mon, Dec 09, 2002 at 11:26:01PM -0800, Zack Weinberg wrote: > Linux is a large project - 4.3 million lines of code - but only one > person has commit privileges on the official tree, for any given > release branch. No matter how good their tools are, this cannot be > expected to scale, and indeed it does not. I have not actually > measured it, but the appearance of the traffic on linux-kernel is that > Linus drops patches on the floor just as often as he did before he > started using Bitkeeper. However, Bitkeeper facilitates other people > maintaining their own semi-official versions of the tree, in which > some of these patches get sucked up. That is bad. It means users > have to choose between N different variants; as time goes by it > becomes increasingly difficult to put them all back together again; > eventually will come a point where critical feature A is available > only in tree A, critical feature B is available only in tree B, and > the implementations conflict, because no one's exerting adequate > centripetal force. > Possibly I am too pessimistic. Actually, the model used for Linux provides substantial freedom. Since no single site is the 'central' site, development can be fully distributed. Changes can be merged back and forth on demand, and remote users require no resources to run, other than the resources to periodically synchronize the data. I think some assesments are wrong here. Linus does get more patches applied these days, and less gets dropped on the floor. Near the end of November, as we were approaching the feature freeze deadline, he was merging on the order of 4MB of code per day if not more. What really ends up happening also is that Linus begins to trust people with entire subsystems. So when Linus pulls changes from their BK tree, he can see if they touch any files outside of their areas of responsibility. Linus used to drop my work often, and I would just retransmit until he took it. Now with BitKeeper, I honestly can't remember the last time he silently dropped a code push I sent to him. The big win with BitKeeper is the whole disconnected operation bit. When the net goes down, I can't check RCS history and make diffs against older versions of files in the gcc tree. With Bitkeeper I have all the revision history in my cloned tree so there is zero need for me to every go out onto the network to do work until I want to share my changes with other people. This also decreases the load on the machine with the "master" repository. There is nothing about this which makes it incompatible with how GCC works today. So if arch and/or subversions can support the kind of model BitKeeper can, we'd set it up like so: 1) gcc.gnu.org would still hold the "master" repository 2) there would be trusted people with write permission who could thusly push their changes into the master tree Releases and tagging would still be done by someone like Mark except it hopefully wouldn't take several hours to do it :-)