Re: source mgt. requirements solicitation

[Momchil Velikov <velco at fadata dot bg>]

>>>>> "Linus" == Linus Torvalds <torvalds@transmeta.com> writes:

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

    Linus> But you don't _undestand_. BK allows hundreds of people to
    Linus> work on the same repository, if you want to. You just give
    Linus> them BK accounts on the machine, the same way you do with
    Linus> CVS.

Ah, I _do_ understand that this is possible.  I _do_ understand very
well that there's no "Linux Kernel Project", but there is "Linus's
kernel tree" .  You seem to not understand that there _is_ "GCC
Project" as well as "GNU Project".

    Linus> But that's not the scalable way to do things. The
    Linus> _scalable_ thing is to let everybody have their own tree,

In that case you don't need a SCM at all - you can do pretty well with
few simple utilities to maintain a number of hardlinked trees.

  "cp -Rl" - branch, tag, fork, whatever
  "share <src> <dst>" - make identical files hardlinks
  "unshare <path>"    - make <path> a file with one link (recursively)
  "dmerge <old> <new> <mine> - same as merge(1), but for trees
  "diff -r" - make a changeset
  "mail" - send a changeset
  "patch" - apply a changeset
  "rm -rf" - transaction rollback, so we have atomicity, see :)

    Linus> and _not_ have that "one common point" disease. You have

This is not a disease, it is a _natural_ consequence of
_collaboration_. And collaboration is an _absolute necessity_ when you
are above certain degree of coupling between the components.  A change
in the network stack can hardly affect the operation of the ATA driver
- however this is not the case in GCC [1].  Changes in particular
phase _do_ affect other phases and this is not a coincidence - it is a
consequence from the fact that GCC components are tightly coupled by
the virtue of working on a common data structure.

The degree module coupling can be characterized as follows [2] (from
loose to tight):

Degree                  Description
------                  -----------
0                       Independent - no coupling

1                       Data coupling - interaction between the
                        modules is with simple, unstructured data
                        types, via interface functions.

3                       Template coupling - interface function
                        parameters include structured data types.

4                       Common data - when modules share common data
                        structure.

5                       Control - when one module controls others with
                        flags, switches, command codes, etc.

The Linux kernel tends to be in {0, 1, 3}.  GCC tends to be in {4, 5}.

IOW, GCC components are roughly from three to five times more tighly
coupled than Linux kernel components.

My point is that the Linux kernel development model [3], while
obviously successful, it not necessarily adequate for other projects,
particularly for GCC.

~velco


[1] AFAICT, I'm not a GCC developer.

[2] there may be other mertics, I've found that one adequate, though
    YMMV.

[3] And, yes, I claim I fully understand it, at least I fully
    understand what _you_ want it to be.