This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: source mgt. requirements solicitation


>>>>> "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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]