VIII Semana de tecnlogia do Barão de Mauá

Controle de Versão 
com Bazaar

Marcelo Barros de Almeida
marcelobarrosalmeida@gmail.com
Direitos de cópia

Créditos ­ ShareAlike 2.0
Você é livre para
copiar, distribuir, apresentar e executar trabalhos
fazer trabalhos derivados
fazer uso comercial deste trabalho
Sob as seguintes condições © Copyright 2008
Créditos. Você deve dar crédito ao autor original.
Marcelo Barros
Compartilhe do mesmo modo. Se você alterar, mudar, 
ou realizar trabalhos usando este como base,você deve 
marcelobarrosalmeida@gmail.com
redistribuir o trabalhos resultante sob uma licença  Correções, sugestões e 
idêntica a esta. traduções são bem vindas!
Para qualquer reuso ou distribuição você deve deixar claro 
os termos de licença deste trabalho.
Qualquer  uma destas condições podem ser abandonadas 
se você obtiver uma permissão do detentor dos direitos 
autorais.
Faça uso justo e o direitos dos outros não serão afetados de 
forma alguma pelas restrições acima.
Texto da licença: 
http://creativecommons.org/licenses/by­sa/2.0/legalcode

2
Marcelo Barros ?

● Formação:
● Engenheiro eletrônico (EFEI, 1996)
● Mestre (UFMG, 1998)
● Doutor (UFMG, 2002)
● Atualmente:
● Engenheiro (Smar Equip. Industriais LTDA)
smar
● Professor do Barão de Mauá
● Detalhes: 
http://linuxabordo.com.br/wiki/index.php?title=Marcelo_Barros
http://jedizone.wordpress.com
3
 Roteiro

 Conceitos de gerência de configuração e controle de 
versão
 Ferramentas para controle de versão disponíveis
 Controle de versão centralizado x distribuído
 Utilizando o Bazaar para controle de versão
 Criando repositórios
 Adicioando/removendo arquivos e diretórios
 Gerenciando TAGs e exportando versões
 Diferenças entre arquivos e desfazendo mudanças
 Ramos e merges
 Usando o Bazaar como servidor 4
 Gerência de Configuração

 Definição:
 ”Conjunto de atividades projetadas para controlar as mudanças 
pela identificação dos produtos do trabalho que serão alterados, 
estabelecendo um relacionamento entre eles, definindo o 
mecanismo para o gerenciamento de diferentes versões destes 
produtos, controlando as mudanças impostas, e auditando e 
relatando as mudanças realizadas”
Roger Pressman, ”Software Engineering: A Practitioner's Approach”

 É uma etapa essencial no processo de desenvolvimento 
de software

5
 Enquete: 
Como você controle o software que produz ?
 Controlar o quê ?
 Precisa controlar ?
 Não controlo
 Vou renomeando os arquivos
 Vou copiando em diretórios
 Vou criando arquivos zips
 Controle de versão descentralizado
 Controle de versão centralizado

6
 Vantagens de se controlar versão

 Cria um histórico do projeto, com todas as mudanças 
realizadas
 Permite um trabalho em equipe
 Permite paralelizar o desenvolvimento através do conceito 
de ramos
 Permite recuperar pontos específicos durante o processo 
de desenvolvimento do software
 Permite correções especificas para determinados clientes
 Se associado a um ”bug tracker”, passa a amarrar as 
mudanças com os motivos da mudança (Mantis, Trac, etc)

7
 Como funciona ?
Versão inicial
 Funcionamento básico:
 Um repositório para o código é criado
 A versão inicial do código é adicionada  Repositório
(local ou 
ao repositório remoto)
 O usuário cria uma cópia de trabalho Revisão n
 Esta cópia sofre alterações
Revisão n+1
 As alterações são consolidadas no 
repositório, devidamente comentadas
 No repositório é mantido o código e o  Usuário
rastreio de todas as mudaças

Modificações

8
 Como funciona ?

 Funcionamento avançado:
Versão original
 Trabalho coletivo, com múltiplas 
cópias de trabalho e vários  Revisão 1
Branch

usuários
Ramo a
 Vários ramos de 
desenvolvimento Revisão 2
Branch
Revisão a1
 Operações de ”merge” para 
unificar trabalhos em ramos  Merge
Revisão a2 Ramo b
diferentes
 Geração de TAGs Revisão 3 Revisão b1

 Operações de ”updates”, para 
atualizar cópias de trabalho

9
 Algumas ferramentas para controle de versão

 Código aberto/gratuitas:  Código fechado/comerciais:
 CVS (Concurrent Version   Clearcase
System)  Sourcesafe
 Subversion  AccuRev
 Bazaar  Perforce
 Git  Plastic SCM
 Mercurial  BitKeeper
 GNU arch  Synergy
 Monotone
 Darcs

Fonte: http://en.wikipedia.org/wiki/Comparison_of_revision_control_software 10
 Centralizado x distribuído
(ou talvez cliente/servidor x peer to peer)
 Centralizado:
 Repositório é mantido num servidor onde o controle 
de acesso e controle geral do projeto é feito
 Desenvolvedores fazem cópias de trabalhos que se 
referenciam ao repositório sempre que alterações 
precisarem ser submetidas
 Distribuído:
 Cada cópia de trabalho é também um repositório 
completo, com direitos locais (não é necessário pedir 
permissão para alterar o repositório local)
 O repositório original não sabe o que é feito em cada 
cópia de trabalho até que ela seja enviada de volta 
pelo desenvolvedor
 Qual o melhor ? Não existe.  É uma decisão 
caso­a­caso Imagens:
http://kids.nationalgeographic.com/Stories/AnimalsNature/Catversusdogroundone
11
http://kids.nationalgeographic.com/Stories/AnimalsNature/Playingfavoritescatordog
 Ferramentas gratuitas e de fonte aberta

 Distribuído:  Centralizado:
 Bazaar  CVS (Concurrent Version 
 Git System)
 Mercurial
 Subversion
 GNU arch
 Monotone
 Darcs

12
 Por que usar Bazaar ?

 Fácil de usar e personalizar, além de bastante flexível
 É escrito em Python (multiplataforma, extensível, ciclos 
rápidos de desenvolvimento)
 Comunidade grande e ativa (Canonical/Ubuntu)
 Gratuito e de fonte aberta
 Repositório eficiente (compacto)
 http://bazaar­vcs.org/
 Desvantagem:
 Um pouco lento para projetos grandes

13
 Sistemas estilo cliente/servidor

 Jargão da área (sistemas centralizados):
 Checkout: ação para criar uma cópia de trabalho
 Commit: ação de enviar modificações feitas na 
cópia de trabalho para o respositório
 Update: significa trazer modificações do 
repositório para a cópia de trabalho
 Branch: ramificação do código fonte em algum 
momento da sua história
 Merge: significa mesclar modificações da cópia de 
trabalho com as de outro branch/versão

14
 Jargão do Bazaar

 Qualquer ramo é um repositório, logo não faz 
sentido em falar de cópia de trabalho.
 Commit: ação para enviar as modificações para o 
repositório
 Branch: ramificação do código fonte em algum 
momento da sua história
 Merge: significa mesclar modificações da cópia de 
trabalho com as de outro branch/versão qualquer
 Push: enviar modificações do ramo para um outro 
ramo, espelho deste
 Pull: trazer modificações de um outro ramo para o 
atual, espelho do anterior
15
 Bazaar: primeiros passos

 Interface de linha de comando*
 bzr  <comando>  <opções>
 Exemplos:
 bzr help commands
 bzr help init
 bzr add arquivo.c
 bzr commit ­m ”versao inicial”
 bzr tag ”V1.0.0”
 bzr branch meuprojet meuprojetov2
 O controle do repositório fica na raiz do projeto, em um 
diretório chamado .bzr
(*) Existem algumas interfaces gráficas mas o uso pela linha de comando é muito simples 16
 Bazaar: criando o repositório

 No ponto onde deseja criar o projeto, 
use o comando init:
 cd /home/trabalhos
 bzr init redes
 Isto gerará um diretório redes e, 
dentro dele, o repositório, 
chamado .bzr
 O repositório está pronto para ser 
usado agora

17
 Bazaar: adicionando arquivos e diretórios

 Crie/copie os arquivos e diretórios necessários para o projeto
 Veja o status dos arquivos como ”desconhecido” com:
 bzr status
 Adicione tudo ao repositório com o command add:
 bzr add
 Por curiosidade, veja agora o status de ”adicionado”:
 bzr status
 Faça o comissionamento das mudanças:
 bzr commit
 Pronto ! O histórico pode ser visto com:
 bzr log
18
 Bazaar: adicionando arquivos e diretórios
$ cd /home/marcelo/projetos/redes/ $ bzr status
$ mkdir source added:
$ mkdir include Makefile
$ touch Makefile include/
$ touch source/luke.c include/yoda.h
$ touch include/yoda.h source/
$ tree source/luke.c
.
|-- Makefile $ bzr commit -m "Versao inicial"
|-- include Committing to:
| `-- yoda.h /home/marcelo/trabalhos/redes/
`-- source added Makefile
`-- luke.c added include
added source
$ bzr status added include/yoda.h
unknown: added source/luke.c
Makefile Committed revision 1.
include/
source/ $ bzr log
-----------------------------------------
$ bzr add revno: 1
added Makefile committer: Marcelo Barros de Almeida
added include <marcelo@dexter>
added source branch nick: redes
added include/yoda.h timestamp: Thu 2008-05-01 15:42:11 -0300
added source/luke.c message:
Versao inicial

19
 Bazaar: comentários sobre adição de 
arquivos e diretórios
 O command add é recursivo, mas pode ser usado com um diretório 
ou arquivo como argumento, para uma ação específica
 bzr add Makefile
 O mesmo é válido para o comando status
 O comentário do comissionamento é obrigatório. Tente sempre 
colocar algo bem conciso e que reflita realmente a mudança
 Durante a vida do projeto, qualquer novo arquivo/diretório deve 
passar pelo comando de adição e comissionamento
 A exclusão é feita através do comando remove, seguido também do 
comissionamento
 Caso o arquivo seja removido diretamente pelo usuário, o Bazaar irá 
também removê­lo na fase de comissionamento
20
 Bazaar: adicionando/removendo arquivos e 
diretórios
$ mkdir doc $ bzr commit -m "trocando luke por vader,
$ touch doc/readme.txt adic. doc"
$ touch source/vader.c Committing to:
$ bzr status /home/marcelo/trabalhos/redes/
unknown: added doc
doc/ added doc/readme.txt
source/vader.c added source/vader.c
deleted source/luke.c
$ bzr remove source/luke.c Committed revision 2.
deleted source/luke.c
$ bzr log
$ bzr add ------------------------------------------
added doc revno: 2
added doc/readme.txt committer: Marcelo Barros de Almeida
added source/vader.c <marcelo@dexter>
branch nick: redes
$ bzr status timestamp: Thu 2008-05-01 16:06:03 -0300
removed: message:
source/luke.c trocando luke por vader, adic. doc
added: -------------------------------------------
doc/ revno: 1
doc/readme.txt committer: Marcelo Barros de Almeida
<marcelo@dexter>
branch nick: redes
timestamp: Thu 2008-05-01 15:42:11 -0300
message:
Versao inicial

21
 Bazaar: criando o repositório à partir de um 
projeto existente
 Se o seu código já reside em <dir>/projeto e precisa ser 
controlado, faça o seguinte:
 cd <dir>/projeto
 bzr init
 bzr add
 bzr commit 

22
 Prática 1: criando repositórios

 Crie um repositório com a seguinte estrutura de arquivos e 
diretórios:
|-- Makefile
|-- doc
| `-- install
|-- inc
| |-- java.h
| `-- perl.h
`-- src
`-- main.c

 Altere os arquivos/diretórios do projeto, comissionando 
depois com mensagens pertinentes
 Adicione e apague arquivos do seu repositório
 Use os comandos status e log quando for conveniente
23
 Bazaar: criando rótulos (TAGs) para o seu 
código
 É comum fazer referências simbólicas ao código, como 
V1.0.1, V5.0.0­RC2, beta10, entre outras
 Este processo, chamado rotulação (tagging), permite 
amarrar um nome simbólico (rótulo) a uma revisão 
específica do código, no decorrer do desenvolvimento
 Isto facilita a referência à versões importantes ou 
entregues para cliente

24
 Bazaar: criando rótulos (TAGs) para o seu 
código
 É comum se usar um esquema  0.9

1.0
de 3 dígitos para nomear uma  0.9.1
1.1
versão.  1.0.1
2.0
0.9.2
 Versões oficiais levam apenas 2  1.1.1
1.0.2
dígitos 0.9.3 2.0.1
1.1.2
 Versões intermediárias levam 3  1.0.3
2.0.2
dígitos 1.1.3

[ major.minor.build ] 2.0.3

 Primeiro dígito: mudanças profundas, alteração de interfaces 
externas
 Segundo dígito: mudanças menores, melhorias, interfaces externas 
mantidas e interfaces internas alteradas, correções graves
 Terceiro dígito: pequenas correções de erros, pequenas mudanças 25
 Bazaar: criando rótulos (TAGs) para o seu 
código
 No Bazaar, é implementado através do comando tag:
 bzr tag <nome_da_versão>
 A revisão corrente será rotulada com nome_da_versão
 Dica: faça o comissionamento antes para assegurar que está 
rotulando a versão correta
 É possível rotular uma revisão existente qualquer:
 bzr tag  <nome_da_versão>  ­r  <revisão>
 Também é permitido apagar um determinado rótulo:
 bzr tag  <nome_da_versão>  ­­delete
 Para listas todas as tags existentes, use:
 bzr tags
26
 Prática 2: criando rótulos (TAGs)

 Modifique o código do seu repositório e adicione tags a 
versões que julgar importante
 Rotule versões antigas através da opção ”­r”
 Experimente apagar TAGs com ”­­delete”
 Use o comando ”tags” e ”log” para listar as tags 
disponíveis e a que revisões elas estão associadas

27
 Bazaar: exportando o código

 Permite gerar uma cópia limpa do 
código, isto é, sem o repositório
 Ideal para enviar por email ou para 
backup
 Suporta vários formatos, como zip, 
tar, tgz,bz2, de forma automática. 
Basta colocar a extensão desejada
 Podem ser usados tanto números de 
revisões como tags

28
 Bazaar: exportando o código

 No Bazaar, é implementado através do comando export:
 bzr export ­r <revisão> <nome_do_arquivo.extensão>
 bzr export ­r tag:<rótulo> <nome_do_arquivo.extensão>
 A revisão especificada será exportada segundo o formato da 
extensão
 Exemplos:
 bzr export ­r 2 ../versao2.zip
 bzr export ­r 3 ../versao2.bz2
 bzr export ­r tag:V1.0  ../Versao_1.0.zip

29
 Prática 3: exportando versões

 Exporte versões do seu repositório, usando tanto revisões 
quanto tags como argumento
 Use também formatos diferentes de arquivos
 Verifique o conteúdo do arquivo exportado. Perceba que 
somente o código fonte puro é exportado
 Use o comando ”tags” e ”log” para listar as tags 
disponíveis e a que revisões elas estão associadas

30
 Bazaar: arrependendimento é possível com 
diff e revert
 diff: lista as diferenças entre duas revisões:
 bzr diff ­r <revisão> [arquivo/diretório]
 Exemplos: 
 bzr diff ­r tag:V1.2  (diferenças entre a revisão atual e a V1.2)
 bzr diff ­r2..3  (diferenças entre as revisões 2 e 3)
 bzr diff ­r 3 src/main.c  (diferenças entre a revisão atual do 
arquivo main.c e a sua revisão 3)
=== modified file 'src/main.c' A versão atual do arquivo main.c 
--- src/main.c 2008-05-06 01:25:08 +0000 (verde) removeu as linhas de 1 a 
+++ src/main.c 2008-05-06 01:33:39 +0000 3 (­1,3) do arquivo original 
@@ -1,3 +1,5 @@ (vermelho), substituindo­as pelas 
+#include <stdio.h> linhas de 1 a 5 (+1,5), a seguir. 
+ As parte alteradas tem um + na 
int main(int){ frente e as partes mantidas ficam 
return 0; inalteradas.
}
31
 Bazaar: arrependendimento é possível com 
diff e revert
 revert: reverte o arquivo para a revisão especificada
 bzr revert ­r <revisao> [arquivo/diretório]
 Exemplos: 
 bzr revert ­r tag:V1.2  (reverte a revisão atual para a V1.2)
 bzr revert ­r 3 src/main.c  (reverte a revisão atual do arquivo 
main.c para a sua revisão 3 correspondente)
 Você pode ir e voltar nas revisões ! Tudo é refeito 
(diretórios/arquivos criados ou apagados). Só não 
esqueça de ter tudo comissionado antes de começar.

32
 Prática 4: diff e revert

 Provoque algumas mudanças, fazendo comissionamento 
entre elas. Depois procure entender a saída do comando 
diff entre a revisão corrente e revisões anteriores.
 Use o comando revert para reverter a revisão atual para 
uma outra revisão qualquer. Fique atento e perceba o que 
foi alterado.

33
 Bazaar: trabalhando com ramos (branches)

 Derivações do projeto principal 
acontecem por vários motivos:
 Implementações de novas características 
de forma controlada
 Divisão do trabalho entre grupo de 
desenvolvedores
 Suporte a versões específicas, com 
correções localizadas
 Ramificações fazem parte da vida de 
um projeto, assim como merges e 
updates

Imagem: Almond Branches in Bloom de Vincent van Gogh
34
 Bazaar: trabalhando com ramos (branches)

 Em sistemas de controle de versão distribuídos, cada 
branch leva consigo toda a informação do repositório. 
Exceções existem, como o ”git”.
 Cada ramo passa a ter vida própria (tem o seu próprio 
repositório .bzr)
 Posteriormente, merges podem ser feitos para que os 
ramos sejam atualizados
 Os ramos carregam informações sobre sua origem para 
facilitar merges futuros

35
 Bazaar: trabalhando com ramos (branches)

 No Bazaar, cada novo ramo é criado com o comando 
branch, da seguinte forma:
 bzr branch <repositório_original> <novo_ramo>
 Um diretório novo_ramo será criado, como um espelho do que 
existia em repositório_original
 Dicas: é mais fácil estar num nível externo ao repositório
 Também é possível usar uma revisão ou TAG como 
referência para a criação de um ramo:
 bzr branch ­r <revisão> <repositório_original> <novo_ramo>
 bzr branch ­r tag:<rótulo> <repositório_original> <novo_ramo>

36
 Prática 5: branches

 Crie ramos do seu repositório
 Faça modificações em cada um deles
 Comissione, gerando revisões localizadas em cada ramo
 Use o comando ”tags” e ”log” para listar as tags 
disponíveis e a que revisões elas estão associadas

37
 Bazaar: atualizando ramos (merge)

 Através do comando merge é possível trazer modificações 
de um ramo qualquer para o ramo atual
 O bazaar tenta unificar as alterações dos dois ramos, de 
forma automática
 Em caso de conflito (alterações na mesma região do 
código em ramos diferentes), será necessário que o 
usuário a resolva manualmente
 É possível ver diferenças entre ramos também. Supondo 
que se está no diretório do repositório, faça:
 bzr diff ­r branch:../<ramo_original>

38
 Bazaar: resolvendo conflitos

 Para cada arquivo em conflito, são criados 3 arquivos, com extensões 
BASE, OTHER e THIS. Um conflito em main.c irá gerar:
 main.THIS: a revisão local do ramo
 main.OTHER: a revisão que veio do outro ramo
 main.BASE: o ancestral comum entre eles
 Além disso, o arquivo main.c terá marcas dentro dele, indicando a área 
de conflito. Resolva o conflito manualmente e faça:
 bzr resolved main.c
 Use uma ferramenta para comparação de fontes, caso tenha dúvida:
 Winmerge, Araxis <<<<<<< TREE
 Kdiff3, meld trecho de código do ramo corrente
=======
 Finalmente, comissione trecho de código do ramo de onde se deseja
obter o merge
>>>>>>> MERGE-SOURCE
39
 Prática 6: merges

 Exercite a função ”merge” entre os seus repositórios 
criados na prática anterior
 Force uma situação onde será necessário resolver um 
conflito de forma manual. Para isto, gere modificações nas 
mesmas linhas de um arquivo, em ramos diferentes. 
Comissione as modificações e tente fazer o merge
 Inspecione os arquivos com extensão THIS, OTHER e 
BASE. Use o comando ”resolved” após resolver o conflito
 Comissione o resultado do merge

40
 Bônus track do Bazaar: acesso remoto

 Para permitir o acesso remoto ao seu repositório, use o 
comando ”server”. Todos os repositórios abaixo do local 
onde o Bazaar for rodado estarão disponíveis via porta 
4155:
$cd /home/marcelo/trabalhos
$ bzr init tcc
$ bzr init redes
$ bzr server
listening on port: 4155

 Use a opção –allow­writes para permitir escritas
$cd /home/marcelo/trabalhos
$ bzr init tcc
$ bzr init redes
$ bzr server --allow-writes
listening on port: 4155

41
 Bônus track do Bazaar: acesso remoto

 Faça um checkout especificando o repositório remoto e 
passe a trabalhar no modelo centralizado:
 bzr checkout bzr://127.0.0.1/tcc
 Ou faça um branch e passe a trabalhar no modelo 
descentralizado:
 bzr branch bzr://127.0.0.1/redes
 No primeiro caso, cada comissionamento irá ser enviado 
ao servidor, já no segundo não. Nesta situação, para 
enviar as mudanças, use o comando push:
 bzr push bzr://127.0.0.1/redes

42
 Referências

 Controle de versão com Bazaar
 http://www.linuxabordo.com.br/wiki/index.php?title=Bazaar
 Comparação entre Ferramentas de Controle de Mudança
 http://www.pronus.eng.br/artigos_tutoriais/analises/ferramentasCon
 Comparison of revision control software
 http://en.wikipedia.org/wiki/Comparison_of_revision_control_soft
ware

43
Dúvidas, comentários, sugestões ?

44
Imagem: cena do filme Madagascar, da DreamWorks