This set of notes is intended mainly for kernel
developers, occasional or full-time, but sysadmins and power users
may find parts of it useful as well. It assumes at least a basic
familiarity with CVS, both at a user level (use on the cmd line)
and at a higher level (client-server model). Due to the author's
background, an operation may be described in terms of CVS, or in
terms of how that operation differs from CVS.
This is -not- intended to be BitKeeper documentation. Always
run bk help <command> or in X bk helptool
for reference documentation.
In the true nature of the Internet itself, BitKeeper is a
distributed system. When applied to revision control, this means
doing away with client-server, and changing to a parent-child
model... essentially peer-to-peer. On the developer's end, this
also represents a fundamental disruption in the standard workflow
of changes, commits, and merges. You will need to take a few
minutes to think about how to best work under BitKeeper, and
re-optimize things a bit. In some sense it is a bit radical,
because it might described as tossing changes out into a maelstrom
and having them them magically land at the right destination... but
I'm getting ahead of myself.