Nonono -- you want to check the linear history from 1.0 to 2.1.130 into
your CVS tree and let all the "dead end" production releases branch off of
that at the exact points they belong.
The simple reason is that the underlying RCS archiver does a lousy job
(i.e., accessing the current kernel gets awfully slow) if you do anything
else.
I've been using PRCS for my kernel tree, and RCS generates really _stupid_
revision numbers for the underlying files if you do not do this.
My diff for 2.1.130-pre3 => 2.1.130 starts like this:
--- dev.133/init/main.c Wed, 25 Nov 1998 13:16:13 +0100 smurf (kernel_linux/i/25_main.c 1.90.1.39.1.6.1.1.1.1.1.2.1.1.1.1.1.1.1.1.1.4.1.1.1.2.1.2.1.1.1.2.1.1.1.1.1.2.3.1.1.4.1.3.1.5.1.2.1.1.1.5.1.1.1.1 644)
+++ dev.134/init/main.c Fri, 27 Nov 1998 08:15:16 +0100 smurf (kernel_linux/i/25_main.c 1.90.1.39.1.6.1.1.1.1.1.2.1.1.1.1.1.1.1.1.1.4.1.1.1.2.1.2.1.1.1.2.1.1.1.1.1.2.3.1.1.4.1.3.1.5.1.2.1.1.1.5.1.1.1.2 644)
[...]
Anyway, any revision control system uses something like a revision tree,
and the only big problem is inserting something you've forgotten between
two existing revisions. But since 2.1.xx branched off of 2.0.21, "inserting"
a 2.0.37 is no problem at all.
-- Matthias Urlichs | noris network GmbH | smurf@noris.de | ICQ: 20193661- 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/