From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1318 invoked by alias); 14 Dec 2002 23:33:16 -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 654 invoked from network); 14 Dec 2002 23:31:55 -0000 Received: from unknown (HELO neon-gw.transmeta.com) (63.209.4.196) by sources.redhat.com with SMTP; 14 Dec 2002 23:31:55 -0000 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id PAA01033; Sat, 14 Dec 2002 15:31:37 -0800 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma001013; Sat, 14 Dec 02 15:31:19 -0800 Received: from home.transmeta.com ([10.8.17.140]) by deepthought.transmeta.com (8.11.6/8.11.6) with ESMTP id gBENVMR27918; Sat, 14 Dec 2002 15:31:22 -0800 (PST) Date: Sat, 14 Dec 2002 16:06:00 -0000 From: Linus Torvalds To: Momchil Velikov cc: zack@codesourcery.com, Subject: Re: source mgt. requirements solicitation In-Reply-To: <87znr8kw4w.fsf@merlin.maxx.bg> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-12/txt/msg00812.txt.bz2 On 15 Dec 2002, Momchil Velikov wrote: > > I surely have a "fork" of GCC and I ain't got nobody's permission. > Permission is needed not when forking, but when merging. But the point is, the "CVS mentality" means that a fork is harder to merge than a branch, and you often lose all development history when you merge a fork as a result of this (yeah, you can do a _lot_ of work, and try to also merge the SCM information on a fork merge, but it's almost never done because it is so painful). That's why I think the CVS mentality sucks. You have only branches that are "first-class" citizens, and they need write permission to create and are very expensive to create. Note: I'm not saying they are slow - that's just a particular CVS implementation detail. By "expensive" I mean that they cannot easily be created and thrown away, so with the "CVS mentality" those branches only get created for "big" things. And the "cheap" branches (private check-outs that don't need write permissions and can be done by others) lose all access to real source control except the ability to track the original. Two of the cheap branches cannot track each other in any sane way. And they have no revision history at all even internally. Yet it is the _cheap_ branches that should be the true first-class citizen. Potentially throw-away code that may end up being really really useful, but might just be a crazy pipe-dream. The experimental stuff that would _really_ want to have nice source control. And the "CVS mentality" totally makes that impossible. Subversion seems to be only a "better CVS", and hasn't gotten away from that mentality, which is sad. > Linus> And a fork is a lot more scalable than a branch. It's also > > There's no difference, unless by "branch" and "fork" you mean the > corresponding implementations in CVS and BK of one and the same > development model. Basically, by "branch" I mean something that fundamentally is part of the "official site". If a branch has to be part of the official site, then a branch is BY DEFINITION useless for 99% of developers. Such branches SHOULD NOT EXIST, since they are fundamentally against the notion of open development! A "fork" is something where people can just take the tree and do their own thing to it. Forking simply doesn't work with the CVS mentality, yet forking is clearly what true open development requires. > IMHO a good metric of the complexity of a particular problem/domain is > the overall ability of the mankind to cope with it. > > Thus, what you describe, may be due to the fact that people capable of > kernel programming are a lot more than people capable of compiler > programming, IOW, that most kernel programming requires rather basic > programming knowledge, compared to most compilers programming. > > No ? No. Sure, you can want to live in your own world, and try to keep the riff-raff out. That's the argument I hear from a lot of commercial developers ("we don't want random hackers playing with our code, we don't believe they can do as good a job as our highly paid professionals"). The argument is crap. It was crap for the kernel, it's crap for gcc. The only reason you think "anybody" can program kernels is the fact that Linux has _shown_ that anybody can do so. If gcc had less of a restrictive model for accepting patches, you'd have a lot more random people who would do them, I bet. But gcc development not only has the "CVS mentality", it has the "FSF disease" with the paperwork crap and copyright assignment crap. So you keep outsiders out, and then you say it's because they couldn't do what you can do anyway. Crap crap crap arguments. Trust me, there are more intelligent people out there than you believe, and they can do a hell of a lot better work than you currently allow them to do. Often with very little formal schooling. > A SCM should facilitate collaboration. Any SCM that requires single > person's permission for modifications to the source base (e.g. by > having only private repositories) is broken beyond repair and scalable > exactly like a BitKeeper^WBKL. But you don't _undestand_. BK allows hundreds of people to work on the same repository, if you want to. You just give them BK accounts on the machine, the same way you do with CVS. But that's not the scalable way to do things. The _scalable_ thing is to let everybody have their own tree, and _not_ have that "one common point" disease. You have the networking people working on their networking trees _without_ merging back to me, because they have their own development branches that simply aren't ready yet, for example. Having a single point for work like that is WRONG, and it's definitely _not_ scalable. Linus