This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: source mgt. requirements solicitation
- From: Momchil Velikov <velco at fadata dot bg>
- To: Linus Torvalds <torvalds at transmeta dot com>
- Cc: zack at codesourcery dot com, <gcc at gcc dot gnu dot org>
- Date: 15 Dec 2002 01:39:59 +0200
- Subject: Re: source mgt. requirements solicitation
- References: <200212142107.gBEL78R23083@deepthought.transmeta.com>
>>>>> "Linus" == Linus Torvalds <torvalds@transmeta.com> writes:
Linus> My tree is often called the "official" tree, but what it
Linus> really is is just a base tree that many people maintain
Linus> their own forks from. This is fundamentally _more_
Err, haven't you noticed that this is the tree that many (all) people
want to merge their forks into ? I think this is "what it really is".
When evaluating a SCM tool, IMHO, the most important is the ease of
merges - remove the need for later merges and any sophisticated "fork"
tool boils down to a "cp -R".
Linus> scalable than the CVS mess that is gcc, since it much more
Linus> easily allows for very radical branches that do not need
Linus> any centralized permission from me.
I surely have a "fork" of GCC and I ain't got nobody's permission.
Permission is needed not when forking, but when merging.
Linus> Think of it this way: in gcc, the egcs split was a very
Linus> painful thing. In Linux, those kinds of splits (people
Linus> doing what they think is right, _without_ support from the
Linus> official maintainers) is how _everything_ gets done. Linux
Linus> is a "constantly forking" project, and that's how
Linus> development very fundamentally happens.
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.
Linus> I would like to point out that Linux development has scaled
Linus> a lot better than gcc, to a larger source base (it's 5+ M
Linus> lines) with much more fundamental programming issues
Linus> (concurrency etc). I will bet you that the Linux kernel
Linus> merges are a lot bigger than the gcc ones, that development
Linus> happens faster, and that there are more independent
Linus> developers working on their own versions of Linux than
Linus> there are of gcc.
How about a different view on the subject ?
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 ?
Linus> Any source control system that has "write access" issues is
Linus> fundamentally broken in my opinion. Your repository should
Linus> be _yours_, and nobody elses. There is no "write access".
Linus> There is only some way to expedite a merge between two
Linus> repositories. The source control management should make it
Linus> easy for you to export your changes to other repositories.
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.
~velco