lkml.org 
[lkml]   [1999]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: The Linux Kernel Project Management System [OT]
    On Mon, Sep 27, 1999 at 10:30:26PM +0000, Aaron Denney wrote:
    > On Mon, 27 Sep 1999 13:42:07 -0700, Larry McVoy <lm@bitmover.com> wrote:
    > > Cool. So explain to us how Aegis handles the following:
    > >
    > > . multiple views, each of which include some subset of the others
    >
    > Well, what exactly do you mean by "multiple views"?

    What we call LOD's or lines of development. This is the feature that Linus
    wants enough that we are holding up BK 1.0 to put it in. Here's the idea:

    Suppose you had several named branches like so

    alan - Alan Cox's work and work that he accepts
    davem - ditto for Dave Miller
    etc.
    linus - Linus's branch where he merges
    linux - The Linux release branch

    Then have a mechanism to bring work from one branch to another, possibly
    skipping some stuff. So Dave might have a good week and Linus accepts
    all of his patches, so the linus branch has everything that the davem
    branch has. But Alan had a bad week, some butthead managed to slip
    something into the alan branch, so his branch looks like

    good.1 - good.2 - bad.1 - good.3

    Linus, being the smart guy that he is, reads the unified diffs which
    he insisted be at the front of each BK patch, and notices that there is
    a bad patch in there. So he whips up the gui tool, finds that part of
    the patch, and says "OK, I'll take the three good ones but exclude the
    bad one". And the system does.

    The really cool part is that BK has a sort of #include facility which
    works across branches - the data for each patch enters the revision
    control system exactly once. Even if it has been included into 27 other
    branches, the file doesn't get bigger (well, not much, each include costs
    about 100 bytes or so of overhead in order to record the fact that the
    data was included in another branch). You simply can't do that in RCS
    - each include would be another copy of the data, making the revision
    history explode in size.

    Credit where credit is due: Marc Rochkind, in the late 70's, came up
    with this idea and implemented it in SCCS. The amazing thing is that
    it has been there all along and people don't use it. What BK does is
    use it under the covers. You think in patches which can have multiple
    changes to multiple files and we group those changes in something called
    a ChangeSet. Then when Linus accepts a patch, he's actually including
    a ChangeSet which exists in Alan's LOD into his LOD.

    What Linus really wants is the ability to include a whole pile of
    ChangeSets all at once. So Alan sends him a patch that has 17 ChangeSets,
    Linus looks at it and says "OK". The "OK" is really a command which says
    "include all this gunk into my LOD in one single ChangeSet". So when
    Linus looks at his LOD all he sees is one thing unless he drills down.
    Drilling down, he sees everything that Alan saw. And it's recursive.
    --
    ---
    Larry McVoy lm@bitmover.com http://www.bitmover.com/lm

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:54    [W:5.308 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site