Messages in this thread | | | Date | Mon, 27 Sep 1999 16:31:09 -0700 | From | Larry McVoy <> | Subject | Re: 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/
| |