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:1.132 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site