Faça download do BitKeeper em http://www.bitmover.com/cgi-bin/download.cgi. Você precisará do Bitkeeper 3.0 ou posterior para acessar nosso repositório.

Siga as instruções para instalá-lo.

Depois que o BitKeeper estiver instalado, primeiro vá ao diretório no qual você deseja trabalhar e então use um dos seguintes comandos para clonar o ramo da versão MySQL de sua escolha:

Para clonar o ramo 3.23 (antigo), use este comando:

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

Para clonar o ramo 4.0 (estável/produção), use este comando:

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

Para clonar o ramo 4.1 alfa, use este comando:

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

Para clonar o ramo de desenvolvimento 5.0, use este comando:

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

Nos exemplos anteriores a árvore binária será configurada no subdiretório mysql-3.23/, mysql-4.0/, mysql-4.1/, ou mysql-5.0/ do diretório atual.

Se você está atrás de um firewall e só pode iniciar conexões HTTP, você também pode o BitKeeper via HTTP.

Se vocÊ precisa usar um servidor proxy, simplesmente configure a variável de ambiente http_proxy para apontar para o seu proxy:

shell> export http_proxy="http://seu.servidor.proxy:8080/"

Agora, simplesmente substitua o bk:// com o http:// ao fazer um clone. Exemplo:

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

O download inicial da árvore fonte pode demorar um pouco, dependendo da velocidade de sua conexão; seja paciente.

Você precisará do GNU make, autoconf 2.53 (ou posterior), automake 1.5, libtool 1.4 e m4 para executar o próximo conjunto de comandos. Embora muitos sistemas operacionais já venham com suas próprias implementações do make, as chances de que a sua compilação falhe com mensagens de erros estranhas são altas. Consequentemente é altamente recomendado usar o GNU make (algumas vezes também chamado gmake).

Felizmente, um grande número de sistemas operacionais já vem com a ferramente GNU pré instalada ou são fornecidos pacotes de instalação da mesma. De qualquer forma, elas podem ser encontradas nos seguintes locais:

Se você estiver tentando configurar o MySQL 4.1 você também precisará do bison 1.75. Versões mais antigas do bison podem exiobir este erro: sql_yacc.yy:#####: fatal error: maximum table size (32767) exceeded. Nota: o tamanho máximo da tabela não é realmente excedido, o erro é causado por um bug nas versões mais novas do bison.

Versões do MySQL anteriores a 4.1 podem também compilar com outras implementações yacc (e.g. BSD yacc 91.7.30). Para versões posteriores, GNU bison é uma exigência.

O comando comum para fazer em uma shell é:

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  # Adicione suas opções favoritas aqui
make

Caso apareçam alguns erros estranhos durantes este estágio, confira se você realmente tem a libtool instalada!

Uma coleção de nossos scripts de configuração padrões está localizada no subdiretório BUILD/. Se preferir, você pode usar BUILD/compile-pentium-debug. Para compilar em uma arquitetura diferente, modifique o script removendo opções que são específicas da arquitetura Pentium.

Quando a construção estiver pronta, execute make install. Seja cuidadoso com isto em uma máquina de produção; o comando pode sobrescrever sua versão atual instalada. Se você tem outra instalação do MySQL, nós recomendamos que você execute ./configure com valores diferentes para as opções prefix, tcp-port e unix-socket-path que as usadas pelo seu servidor em produção.

Seja rígido com sua nova instalação e tente fazer com que os novos recursos falhem. Inicie executando make test. See Secção 14.1.2, “Pacotes de Teste do MySQL”.

Se você chegar ao estágio make e a distribuição não compilar, por favor relate-o para <bugs@lists.mysql.com>. Se você instalou as últimas versões das ferramentas GNU exigidas, e elas falharam tentando processar nossos arquivos de configuração, por favor informe isto também. Entretanto, se você executar aclocal e obtêm um erro de command not found não o reporte.Tenha certeza que todas as ferramentas necessárias estejam instaladas e que sua variável PATH esteja corretamente configurada para que sua shell possa encontrá-la.

Depois da operação inicial bk clone para obter a árvore fonte, você deve executar bk pull periodicamente para obter as atualizações.

Você pode examinar o histórico de alterações para a árvore com todos os diffs usando bk sccstool. Se você ver alguns diffs estranhos ou código sobre o qual você tenha alguma dúvida, não hesite em enviar um e-mail para lista de email ``internals'' do MySQL. See Secção 1.7.1.1, “As Listas de Discussão do MySQL”. Além disso, se você acha que tem uma idéia melhor em como fazer algo, envie um email para o mesmo endereço com um patch. bk diffs irá produzir um patch para você após fazer as alterações no código fonte. Se você não tiver tempo para codificar sua idéia, apenas envie uma descrição.

BitKeeper tem um ótimo utilitário de ajudar que você pode acessar via bk helptool.

Note que qualquer commit (bk ci ou bk citool) irá disparar o envio da mensagem com as alterações para nossa lista de email internos, bem como a submissão openlogging.org usual apenas com os comentários da alteração. Geralmente você não precisar usar commit (já que o árvore pública não permitirá bk push), mas é preferível usar o método bk diffs descrito arteriormente.