This is the mail archive of the
mailing list for the GCC project.
Re: source mgt. requirements solicitation
- From: Linus Torvalds <torvalds at transmeta dot com>
- To: Momchil Velikov <velco at fadata dot bg>
- Cc: zack at codesourcery dot com, <gcc at gcc dot gnu dot org>
- Date: Sat, 14 Dec 2002 15:32:51 -0800 (PST)
- Subject: Re: source mgt. requirements solicitation
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
> 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
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 ?
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.