Re: The history of the Linux OS

David Luyer (luyer@ucs.uwa.edu.au)
Thu, 26 Nov 1998 11:41:18 +0800


> If you insist on using RCS version numbers you'll have a problem anyway: in
> RCS you have to treat revision numbers as dotted pairs. Well, you don't
> absolutely *have* to, but various commands assume <branchID, revision>
> relationships between pairs of numbers, so "1.2.129" could not be easily
> represented in RCS except as 1.1.2.1.129.1. You DON'T want to go there,
> trust me.

If RCS supports branches, things become awfully trivial.

A new, old tree which shows up can be entered efficiently as a branch
off the kernel revision before it? Then why are people still going on about
how impossible it is to insert between revisions? Define a decent tree
structure and you're all done.

Root of tree: nothing
Branch for each major revision development kernel
(eg -- 2.1.0 is represented as a diff from 2.0.0, but 2.0.0 is a
diff from 1.3.99)
Further revisions for each _official_ patch on top of them
Sub-branch for each pre-patch on top of them

Define the starting tree to be what's currently on ftp.kernel.org and
enter any 'newly found' patches as sub-branches just like pre-patches.

And, wow, you're done. No need to keep discussing it, just do it.

If this isn't possible, then you may have a problem if 2.0.37 comes out
after you form your tree, just the same as you'd have a problem if you
found an official linux-0.50 after you form your tree. And when 2.3.x is
in development, 2.2.x is almost certain to be still getting patches.

David.

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