Appendix B: Administration

BitKeeper is designed to work ``out of the box'' but it was also designed with flexibility in mind. It is possible to change the default configuration of the look and feel, to set up a list of files to be ignored by BitKeeper, and to enforce a software development policy you have in mind. This section describes how to do those things, plus gives you instructions on what to do if something ``goes wrong''.

Backups

One way to back up a repository is to have a trigger to push to a mirror repository every time an incoming push to the master repository occurs. So, if a developer pushes into Master, master pushes to the mirror. And the mirror only accepts pushes from Master, no one else. For more information see

bk helptool triggers

Another way to do this is with traditional backup tools. BitKeeper repositories with no pending files can be safely backed up with any backup tool, such as tar or dump, etc. To see if there are any pending files, run

bk pending

No output indicates no pending files.

WARNING
If the repository has pending files (files which are checked in but not yet committed to a changeset), then saving and restoring the repository should be done carefully. Problems can arise if the repository is restored multiple times and the same pending deltas are committed to different changesets. In other words, the following will cause problems:

cd REPO bk edit foo.c echo "I am a pending delta not yet committed" >> foo.c bk delta -yPENDING foo.c cd .. cp -r REPO COPY cd REPO bk commit cd ../COPY bk commit

Why is it a problem? Because the two commits both created a changeset, and the changesets are different. This means that the same delta to foo.c now belongs to two different changesets. It is not fatal when this happens, but it may make it difficult to roll backwards to this point.