lkml.org 
[lkml]   [1998]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: The history of the Linux OS
Date
: In message <199811232356.PAA12496@bitmover.com>, Larry McVoy writes:
: +-----
: | You may not like that you can't apply 1.1.47 as a child of 1.1.1 but
: | that's the way it has to work. Anyone who tells you differently is
: | just telling you what you want to hear.
: +--->8
:
: That implies that Bitkeeper can only be used for complete trees. So we
: can't use it until we've found *all* the kernel revisions. :-( OTOH we're
: not really talking about revision control, so Bitkeeper or other complex
: revision control packages aren't necessarily the appropriate tools for the
: task.
:
: It does work to ignore relationships between revisions and check them in in
: any order, then use e.g. CVS tags to identify particular kernel releases.
: The underlying RCS files will not be optimal, but it will work --- because
: this is not really a revision control tree we're discussing, but a revision
: history. We don't need (or intend) to store file revisions that don't
: correspond to kernel releases, or to track/"micromanage" current
: development. Every so often the tree could be dumped and rebuilt in the
: proper order to reduce the size of the RCS files, but this wouldn't have to
: be done every time a new kernel release were found and added to the tree.
:
: If we were going to use this as the kernel development tree as well as a
: historical reference, it would indeed be an absolute nightmare and
: unworkable in practice. But we aren't, so we can get away with an abuse of
: the relationship between CVS and RCS.

With no offense intended, I disagree.

The whole point of having things under revision control is so that you
can browse them, in the order that the events happened, not in some random
order which corresponds to when you happened to find some old kernel.

As to the tree itself, I'll take responsibility for checking in what we have
archived to date and providing that tree as a basis for future work. Once
we have that basis, there are no ordering problems, at least none that you
need to get around.

Let me try and be a bit more clear about that last claim. It's true that
if you are at version 1.100 in your copy of the source and patch which
consists of the diffs from 1.200 .. 1.203 comes by, BitKeeper will not
allow you to patch that into your tree. Under no circumstances, not even
if Cindy Crawford showed up and begged, would I change that behaviour (she's
welcome to show up and try to convince me, however :-)

The reason is that "the source" is a distributed thing. There are
copies of the same files all over the world. You guys all want that
managed well so that you can do your work in a distributed fashion with
a minimal amount of fuss. If you start changing around the order of
events in the revision control graph, there is nothing that any tool can
do to help you. On the other hand, if you don't violate the ordering,
then I can answer questions, programatically, like "does the latest
release from Linus have everything that is in my tree or not?"

Another example of where this ordering can be an issue is Linus'
infamous editing of unified diffs before he applies them to his tree.
That is a problem because the diffs represent the events (deltas) made
by someone else. When Linus edits those diffs, that's a new event.
If he applies the modified diffs before applying the pristine diffs,
then when you ask "are my diffs in the tree?" the answer will be "no"
because your diffs aren't in the tree. What is in the tree is your diffs
plus Linus' changes, *as one delta*. And that delta is different than
the one delta you made in your tree.

So how do we get around this? The correct set of changes is whatever
you did plus whatever Linus did as two distinct events. But Linus is
in a hurry, so he wants to *think* that he can just edit the diffs
and apply them. So I'll make a little tool, maybe we can call the
"linustool", which lets him hack on the diffs and then applies them for
him. But what it really does is save away a copy of the diffs, get the
(possibly hacked) diffs from Linux when he says "apply", diff the diffs,
if they are changed, apply the first set as your changes, and then apply
the mods to that set as his change. It sounds complicated and I'm sure
it will be a little dicey, but I'm also sure I can build that tool.
So everyone is happy - Linus gets to work the way he wants and we can
still preserve the invariants required to have a distributed source base.

If this is clear as mud, you're welcome to send me mail with questions or
if hte list can stand it, we can discuss it here.

Cheers,

--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:45    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site