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.
-- brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net system administrator [WAY too many hats] allbery@ece.cmu.edu carnegie mellon / electrical and computer engineering KF8NH Kiss my bits, Billy-boy.
- 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/