http://www.bitmover.com/cgi-bin/download.cgi から BitKeeper をダウンロードする。当社のリポジトリにアクセスするには、Bitkeeper 3.0 以降が必要である。

指示に従って、ダウンロードした BitKeeper をインストールする。

BitKeeper をインストールしたら、まず、作業するディレクトリに移動する。次に、以下のいずれかのコマンドを使用して、必要な MySQL バージョンブランチをコピーする。

3.23（旧バージョン）ブランチをコピーするには、以下のコマンドを使用する。

shell> bk clone bk://mysql.bkbits.net/mysql-3.23 mysql-3.23

4.0（安定版/製品版）ブランチをコピーするには、以下のコマンドを使用する。

shell> bk clone bk://mysql.bkbits.net/mysql-4.0 mysql-4.0

4.1 alpha ブランチをコピーするには、以下のコマンドを使用する。

shell> bk clone bk://mysql.bkbits.net/mysql-4.1 mysql-4.1

5.0 開発ブランチをコピーするには、以下のコマンドを使用する。

shell> bk clone bk://mysql.bkbits.net/mysql-5.0 mysql-5.0

上記の例では、カレントディレクトリの、mysql-3.23/、mysql-4.0/、mysql-4.1/、mysql-5.0/ のいずれかのサブディレクトリにソースツリーがセットアップされる。

ファイアウォールの背後にいて、HTTP 接続しか開始できない場合は、HTTP を通じて BitKeeper を使用することもできる。

プロキシサーバを使用する必要がある場合は、使用するプロキシを指すように環境変数 http_proxy を設定する

shell> export http_proxy="http://your.proxy.server:8080/"

次に、コピーを実行するときに、bk:// を http:// に置き換える。たとえば、以下のように指定する。

shell> bk clone http://mysql.bkbits.net/mysql-4.1 mysql-4.1

接続の速度によって、ソースツリーの初期ダウンロードには多少時間がかかることがある。

次の一連のコマンドを実行するには、GNU make、autoconf 2.53 (以降)、automake 1.5、libtool 1.4、および m4 が必要である。多くのオペレーティングシステムには独自の make 実装が搭載されているが、未知のエラーメッセージが出力されてコンパイルが失敗する可能性が高い。したがって、必ず GNU make （gmake と呼ばれることもある）を使用する。

幸い、多くのオペレーティングシステムは GNU ツールチェーンがプリインストールされているか、インストール可能な GNU ツールのパッケージを提供する。いずれの場合も、以下の場所からダウンロードすることもできる。

MySQL 4.1 をコンフィギャする場合は、GNU bison 1.75 も必要である。旧バージョンの bison は、次のようなエラーを報告することがある。 sql_yacc.yy:#####: fatal error: maximum table size (32767) exceeded。 注意: 実際に最大テーブルサイズを超過しているわけではない。このエラーは、旧バージョンの bison のバグが原因で発生する。

バージョン 4.1 より前の MySQL バージョンは、他の yacc 実装（BSD yacc 91.7.30 など）によってもコンパイルする。4.1 以降のバージョンの場合は、GNU bison は必要条件である。

シェルで実行する標準的なコマンドは以下のとおりである。

cd mysql-4.0
bk -r edit
aclocal; autoheader; autoconf; automake
(cd innobase; aclocal; autoheader; autoconf; automake) # for InnoDB
(cd bdb/dist; sh s_all ) # for Berkeley DB
./configure  # Add your favorite options here
make

この段階で未知のエラーが発生した場合は、libtool が実際にインストールされているかどうかをチェックする。

当社の標準 configure スクリプトのコレクションは、BUILD/ サブディレクトリにある。手間を省きたい場合は、BUILD/compile-pentium-debug を使用することもできる。別のアーキーテクチャ上でコンパイルするには、このスクリプトから Pentium 固有のフラグを削除して修正する。

ビルドが完了したら、make install を実行する。実稼動マシン上でこれを行う場合は、このコマンドによって稼動中のリリースインストールが上書きされるという点に注意する。別の MySQL がインストールされている場合は、prefix、with-tcp-port、unix-socket-path の各オプションに実稼動サーバで使用している値と異なる値を設定して、./configure を実行することをお勧めする。

新しいインストールを酷使して、新しい機能をクラッシュさせてみる。make test の実行から始める。 See 項13.1.2. 「MySQL テストスイート」。

make の段階に到達しても、ディストリビューションがコンパイルできない場合は、http://bugs.mysql.com/ にあるバグデータベースに報告をお願いしたい。必要な GNU ツールの最新バージョンがインストールされていて、それらのツールが設定ファイルの処理中にクラッシュする場合も同様である。 ただし、aclocal を実行して command not found というエラーや類似の問題が発生した場合は、報告は不要である。代わりに、必要なツールがすべてインストールされているかどうかと、シェルがそれらのツールを検出できるように PATH 変数が正しく設定されているかどうかを確認する。

ソースツリーを取得するための最初の bk clone 操作の後、定期的に bk pull を実行して更新を入手する。

bk sccstool を使用して、ツリーの変更履歴ですべての diff を調べることができる。不明な diff やコードがあった場合は、MySQL の内部メーリングリストにメールをお送りいただきたい。 See 項1.7.1.1. 「MySQL メーリングリスト」。 また、何かに関する修正案がある場合も、同じアドレスにパッチを添付したメールをお送りいただきたい。 bk diffs は、ユーザがソースを変更するとパッチを作成してくれる。アイデアをコードにする時間がない場合は、説明だけでもお送りいただきたい。

BitKeeper には、bk helptool を使用してアクセスできる便利なヘルプユーティリティがある。

注意: いずれのコミット（bk ci または bk citool）も、当社の内部メーリングリストへのチェンジセットを含んだメッセージの投稿や、ChangeSet コメントだけが含まれた通常の openlogging.org サブミッションをトリガすることはない。 一般に、コミットを使用する必要はない（公開ツリーは bk push を許可しないため）が、前述した bk diffs メソッドは使用する。