Sistemas de Controle de Versão

Transcrição

1 Sistemas de Controle de Versão Juliano F. Ravasi Setembro /

2 Conteúdo Parte 1: Controle de Versões Parte 2: Trabalhando com Subversion Parte 3: Trabalhando com Mercurial 2

3 Controle de Versões 3

4 Motivação O que é controle de versões? Gerenciamento de múltiplas revisões Documentos, projetos, software, etc. Histórico de alterações sofridas Permitir consultar revisões anteriores Permitir comparações entre revisões Permitir trabalho cooperativo 4

5 Motivação O que é controle de versões? Vários nomes: Revision control system (RCS) Version control system (VCS) Software Configuration Management (SCM) Source Code Management Source Control Controle de versão não é exclusivo para gerenciamento de software. 5

6 Motivação Por que controle de versões? Software é algo caro de ser produzido Consome muito tempo Exige cooperação, organização, disciplina É importante armazenar tudo que é feito 6

7 Motivação Onde é utilizado? Sistemas de arquivos Suítes de escritório Ambientes colaborativos Gerenciamento de software Importante para qualquer desenvolvedor ou empresa de desenvolvimento de software. 7

8 Motivação Onde é utilizado? 8

9 Motivação Onde é utilizado? 9

10 Recursos Registro de revisões Toda alteração realizada é registrada Rápido acesso a revisões anteriores Quem, quando, o que e por quê? Nada é perdido para sempre Descartar código ruim sem remorso Determinar introdução de defeitos Manutenção de código legado 10

11 Recursos Auditoria Comparação entre versões do projeto, mostrando diferenças linha-a-linha Apontar desenvolvedores responsáveis por cada trecho de código do projeto Automação de testes de estabilidade 11

12 Recursos Ramificações Múltiplas linhas de desenvolvimento dentro do mesmo projeto Permite divergência e reconvergência do desenvolvimento 12

13 Recursos Trabalho cooperativo Vários desenvolvedores trabalhando sobre o mesmo projeto Mescla das alterações dos diversos desenvolvedores ou ramificações 13

14 Recursos Segurança Autenticação criptográfica de histórico Controle de acesso sobre o repositório Cópias de segurança (backup) 14

15 Modelos Centralizado (cliente-servidor) Distribuído Um repositório central de revisões Desenvolvedores obtém cópias de trabalho do repositório central Cada desenvolvedor tem seu repositório Desenvolvedores copiam repositórios e alterações de outros desenvolvedores 15

16 Modelos Centralizado (cliente-servidor) Vantagens: Desvantagens: Controle de acesso Cópia de segurança Controle de qualidade Dependência do repositório central Ponto único de falha 16

17 Modelos Distribuído Vantagens: Desvantagens: Permite submissões particulares, offline Melhor suporte a ramificação e mescla Independência da rede, mais rápido Estimula o isolamento de desenvolvedores Questões de privacidade e segurança 17

18 Modelos Centralizado vs. distribuído Assunto quente nos últimos anos Há sobreposição entre os modelos Ferramentas distribuídas podem ser usadas no modelo centralizado, quando necessário Ainda não existe a ferramenta perfeita Opiniões inflamadas, guerra de egos Cada modelo de desenvolvimento exige um modelo de controle de versões 18

19 Conceitos Repositório Núcleo do controle de versões Possui uma linha do tempo embutida Coletânea de revisões do projeto 19

20 Conceitos Repositório Revisão Estado em um determinado instante Imutável após criada 20

21 Conceitos Cópia de trabalho Cópia do repositório em certa revisão Geralmente a mais recente Checkout (obtenção de uma cópia) 21

22 Conceitos Cópia de trabalho Onde ocorre o desenvolvimento O sistema reconhece as alterações feitas Algumas operações devem ser explícitas Adição, remoção, moção e cópia de arquivos 22

23 Conceitos Cópia de trabalho Submissão (commit) Alterações são registradas em uma nova revisão do repositório 23

24 Conceitos Ramificações (branches) Linhas alternativas de desenvolvimento Explícitas Implícitas 24

25 Conceitos Ramificações (branches) Explícitas Manutenção de versões legadas Implementação de novos recursos Experiências no código do projeto 25

26 Conceitos Ramificações (branches) Implícitas Cópia de trabalho Múltiplos desenvolvedores 26

27 Conceitos Mescla (merge) Reintegração de ramificações Em grande parte é automatizado Conflitos podem ocorrer O desenvolvedor pode precisar interagir 27

28 Conceitos Rótulos (tags) Nomes atribuídos a revisões 28

29 Gerenciamento de software Fluxos de trabalho Solitário Centralizado Distribuído Repositório local Repositório remoto Parceiro Equipe Hierárquico 29

30 Gerenciamento de software Fluxos de trabalho Solitário 30

31 Gerenciamento de software Fluxos de trabalho Centralizado, repositório local 31

32 Gerenciamento de software Fluxos de trabalho Centralizado, repositório remoto 32

33 Gerenciamento de software Fluxos de trabalho Distribuído, parceiro 33

34 Gerenciamento de software Fluxos de trabalho Distribuído, equipe 34

35 Gerenciamento de software Fluxos de trabalho Distribuído, hierárquico 35

36 Gerenciamento de software Sistemas de controle de versões SourceAnyware Vault Git darcs MOG ArX Surround FtpVC PlasticSCM CVS Store Stellation ClearCase Vesta AllFusion SourceSafe DCVS Aegis PureCM GNU arch Mercurial RCS Team Foundation Server FirePublish Team Coherence SourceHaven Perforce CodeVille Fossil codebeamer MKS QVCS TeamWare Code Co-op AccuRev Evolution DesignSync SVK Serena FileHamster Aldon AVS CVSNT Subversion OpenCVS LibreSource AlienBrain StarTeam BitKeeper Synergy Monotone Bazaar 36

37 Gerenciamento de software Sistemas de controle de versões Centralizado Aegis CVSNT CVS Aberto Distribuído OpenCVS CodeVille Stellation Subversion ArX arch Fossil Vesta darcs Git Bazaar DCVS LibreSource Mercurial Monotone SVK AccuRev Aldon AlienBrain AllFusion Proprietário AVS ClearCase codebeamer DesignSync Evolution FileHamster FirePublish Perforce FtpVC MKS PureCM QVCS SourceAnyware SourceSafe Code Co-op MOG Serena SourceHaven StarTeam BitKeeper TeamWare Store Surround Synergy Team Coherence Vault PlasticSCM Team Foundation Server 37

38 Gerenciamento de software Sistemas de controle de versões Visão geral dos VCSs abertos: Centralizados: Git Mercurial Bazaar Mais: Distribuídos: CVS Subversion

39 Sistemas de controle de versão CVS Criado para substituir o RCS (1980s) Obsoleto, desenvolvimento estagnado Modelo centralizado Possui grande base de usuários Possui defeitos e limitações de projeto Escrito em C, monolítico 39

40 Sistemas de controle de versão Subversion Sucessor do CVS Projetado para contornar os seus defeitos Desenvolvido por CollabNet Inc. Modelo centralizado Robusto e maduro Ênfase em qualidade, larga escala Sem restrições a tipos de arquivos Escrito em C, modular 40

41 Sistemas de controle de versão Subversion Projeto em camadas Repositório Acesso ao repositório Bindings: C, Python, Perl, Java, Ruby Cliente Local, WebDAV, svnserve Cópia de trabalho Biblioteca de cliente BorlandDB, fsfs svn, TortoiseSVN, Subclipse, KDESvn, Trac,... 41

42 Sistemas de controle de versão Git Criado para gerenciar o kernel do Linux Após controvérsia sobre o BitKeeper Inspirado no Monotone Inicialmente por Linus Torvalds Modelo distribuído Ênfase em desenvolvimento não-linear Autenticação criptográfica do histórico Gerencia conteúdo, ao invés de arquivos Escrito em C, monolítico 42

43 Sistemas de controle de versão Mercurial Criado simultaneamente ao Git Inspirado no Monotone Desenvolvido por Matt Mackall Modelo distribuído Autenticação criptográfica do histórico Ênfase em uso por grandes projetos Escrito em Python, modular 43

44 Sistemas de controle de versão Bazaar Desenvolvido por Canonical Inc. Modelo distribuído Ênfase em facilidade, flexibilidade Suporte a múltiplos fluxos de trabalho Desempenho ruim Escrito em Python, modular 44

45 Gerenciamento de software O que armazenar? Arquivos produzidos pelo desenvolvedor: código fonte scripts de automação documentação escrita figuras, imagens e ícones possivelmente apenas os originais, usando ferramentas automáticas para converter entre formatos e tamanhos makefiles a menos que sejam criados por um processo automático (por ex:./configure) 45

46 Gerenciamento de software O que não armazenar? Arquivos gerados automaticamente: código-objeto programas compilados documentação automática Arquivos com configurações locais: credenciais de acesso a banco-de-dados Arquivos criados acidentalmente: core dumps arquivos temporários 46

47 Trabalhando com Subversion 47

48 Trabalhando com Subversion Características gerais Repositório vs. cópia de trabalho Ramificações, rótulos Implícito, parte da árvore do repositório Criados através de cópias leves Características únicas: Armazenados em lugares distintos Propriedades Diretórios WebDAV 48

49 Trabalhando com Subversion Características gerais Recomendação Usar versão 1.5 ou superior. Informações Projeto: Manual: Clientes: Windows: Eclipse: KDE: 49

50 Trabalhando com Subversion Repositório Sistema de arquivos Baseado em ligações Revisões numéricas, seriais Revisão zero: repositório em branco Sugestões de organização: Cópias leves, copy-on-write Banco-de-dados transacional Um repositório por projeto (incluindo subprojetos) 50

51 Trabalhando com Subversion Repositório Criação do repositório svnadmin create diretório Cria um novo repositório Subversion em branco (revisão zero) em diretório. Convenções de hierarquia / trunk/ branches/ tags/ tronco ramificações rótulos 51

52 Trabalhando com Subversion Repositório Convenções de hierarquia 52

53 Trabalhando com Subversion Repositório Criação da hierarquia inicial Método 1: svn checkout file:///home/user/svn/repo cd repo svn mkdir trunk branches tags svn commit -m "Directory hierarchy." Método 2 (bash): r=file:///home/user/svn/repo svn mkdir $r/{trunk,branches,tags} -m "..." 53

54 Trabalhando com Subversion Ciclo de trabalho 1. Obtenção (checkout) svn checkout ❶ svn checkout 54

55 Trabalhando com Subversion Ciclo de trabalho 2. Desenvolvimento ❷ (edição) 55

56 Trabalhando com Subversion Ciclo de trabalho 3. Comparação, reversão svn status svn diff svn revert ❸ svn diff svn revert 56

57 Trabalhando com Subversion Ciclo de trabalho 4. Submissão svn commit ❹ svn commit 57

58 Trabalhando com Subversion Ciclo de trabalho 5. Atualização svn update ❺ svn update 58

59 Trabalhando com Subversion Comandos Ferramentas principais: svn svnadmin Manutenção do repositório. Outras ferramentas: Cliente padrão, cópia de trabalho. svndumpfilter svnlook svnserve svnsync 59

60 Trabalhando com Subversion Comandos Acesso ao repositório Local WebDAV sobre HTTP svn://svn.example.com/svn/repo/... svnserve sobre SSH svnserve file:///home/user/svn/repo/... svn+ssh://svn.example.com/svn/repo/... 60

61 Trabalhando com Subversion Comandos Acesso ao repositório Composição da URL svn://svn.example.com/svn/project/subproject/trunk/ Endereço do servidor Subversion Endereço do repositório Caminho armazenado no repositório 61

62 Trabalhando com Subversion Comandos Importação svn import [diretório] URL Obtenção svn checkout URL [diretório] Obtém uma cópia de trabalho. svn export URL [diretório] Obtém uma cópia limpa do projeto. svn update [diretório] Importa um projeto existente em um repositório. Atualiza a cópia de trabalho com o repositório. 62

63 Trabalhando com Subversion Comandos Edição svn add alvo svn delete alvo Cria uma cópia de um arquivo ou diretório. svn move orig dest Cria um diretório no controle de versão. svn copy orig dest Remove um arq./dir. do controle de versão. svn mkdir diretório Adiciona um arq./dir. ao controle de versão. Move ou renomeia um arquivo ou diretório. 63

64 Trabalhando com Subversion Comandos Consulta e comparação svn status [alvo] svn diff [alvo] Mostra alterações realizadas em arquivos. Reversão svn revert [alvo] Mostra arquivos alterados, adicionados, etc. Reverte alterações realizadas em arquivos. 64

65 Trabalhando com Subversion Comandos Submissão svn update svn commit [alvo] Atualiza a cópia de trabalho antes de submeter, opcional. Podem ocorrer conflitos ao mesclar as alterações do repositório com as suas. Submete o estado atual da cópia de trabalho para o repositório, criando uma nova revisão. Nesse processo, é necessário fornecer uma breve descrição das alterações realizadas. 65

66 Trabalhando com Subversion Comandos Resolução de conflitos svn resolve --accept arg [alvo] svn resolved alvo Informa que o conflito foi manualmente resolvido, e destrava a cópia de trabalho. svn status svn commit [alvo] Resolução simples, informa qual versão do alvo deverá ser preservada. Após resolver os conflitos, tentar submeter novamente. 66

67 Trabalhando com Subversion Comandos Informação e auditoria svn info [alvo] svn log [alvo] Mostra registro de alterações de um arquivo, diretório ou do projeto. svn blame arquivo Mostra informações diversas sobre a cópia de trabalho ou o alvo fornecido. Acusa os desenvolvedores que alteraram por último cada linha de um arquivo. 67

68 Trabalhando com Subversion Consulta de histórico (svn log) r3 juliano :41: (Fri, 18 Jul 2008) 8 lines Changed paths: M /trunk A /trunk/calculatorform.cpp A /trunk/calculatorform.h A /trunk/calculatorform.ui M /trunk/calculator.cpp M /trunk/calculator.pro User interface design. Designed the user interface of the calculator, using Qt Designer. No functions have been implemented yet. The calculator is non-functional. Added some patterns for generated files to svn:ignore. 68

69 Trabalhando com Subversion Atualização (svn update) Para visitar revisões passadas Para retornar à última revisão svn update Legenda svn update -r revisão svn update -r {data} A: D: U: C: G: E: adicionado apagado atualizado conflito mesclado já existente (Added) (Deleted) (Updated) (Conflicted) (merged) (Existed) 69

70 Trabalhando com Subversion Comparação (svn diff) Alterações na cópia de trabalho svn diff [alvo] Comparar revisões arbitrárias svn diff -r x:y [alvo] svn diff -c x [alvo] Alterações entre revisões x e y. Alterações entre revisões x -1 e x. 70

71 Trabalhando com Subversion Comparação (svn diff) 71

72 Trabalhando com Subversion Consulta de estado (svn status) Legenda adicionado (Added) em conflito (Conflicted) apagado (Deleted) ignorado (Ignored) modificado (Modified) substituído (Replaced) item externo (external) item desconhecido, não controlado item controlado, porém ausente Mais detalhes A: C: D: I: M: R: X:?:!: svn help status 72

73 Trabalhando com Subversion Ramificações Comandos svn copy repo/trunk repo/branches/branch svn switch repo/trunk svn switch repo/branch/branch Cria uma nova ramificação. Alterna entre ramificações. 73

74 Trabalhando com Subversion Mescla e reversão Mescla entre ramificações svn merge URL svn merge --reintegrate URL Reintegra alterações de uma ramificação ao tronco. svn merge -c rev URL Mescla alterações de uma ramificação diferente na ramificação atual da cópia de trabalho. Mescla apenas revisão rev. 74

75 Trabalhando com Subversion Mescla e reversão Reversão svn merge -c -rev URL Desfaz as alterações da revisão rev. Pode ser usado na própria ramificação. É uma mescla ao contrário. 75

76 Trabalhando com Subversion Rótulos Caso especial de ramificação São usados apenas como referência Devem ser somente-leitura após criados. Comando svn copy repo/trunk repo/tags/tag Cria um novo rótulo. 76

77 Trabalhando com Subversion Propriedades Comandos svn proplist [alvo] svn propget prop alvo Altera uma propriedade (no editor externo). svn propdel prop alvo Configura o conteúdo de uma propriedade. svn propedit prop alvo Recupera conteúdo de uma propriedade. svn propset prop cont alvo Lista propriedades. Apaga uma propriedade. 77

78 Trabalhando com Subversion Propriedades Propriedades padrão Diretórios e arquivos Revisões svn:eol-style svn:executable svn:externals svn:ignore svn:keywords svn:mime-type svn:needs-lock svn:author svn:date svn:log 78

79 Trabalhando com Mercurial 79

80 Trabalhando com Mercurial Características gerais Distribuído Ramificações, rótulos Cópia de trabalho contém o repositório: São armazenados juntos Explícitos, possuem tratamento especial Cada cópia de trabalho é uma ramificação 80

81 Trabalhando com Mercurial Características gerais Informações Projeto: Manual: Clientes: Windows: Eclipse: 81

82 Trabalhando com Mercurial Repositório Sistema de arquivos Armazenamento eficiente, seguro e rápido Revisões: Sugestões de organização: Numéricas, seriais Hash SHA-1 do changeset Um repositório por subprojeto Projeto: vários subprojetos agrupados 82

83 Trabalhando com Mercurial Ciclo de trabalho 1. Início do projeto (init) hg init ➊ hg init 83

84 Trabalhando com Mercurial Ciclo de trabalho 2. Desenvolvimento, submissão local hg status, diff, revert, commit ➋ hg hg hg hg status diff revert commit 84

85 Trabalhando com Mercurial Ciclo de trabalho 3. Ramificação hg clone ➌ hg clone 85

86 Trabalhando com Mercurial Ciclo de trabalho 4. Mais desenvolvimento ➍ hg hg hg hg status diff revert commit ➍ hg hg hg hg status diff revert commit 86

87 Trabalhando com Mercurial Ciclo de trabalho 5. Mescla hg pull, push ➎ hg pull hg push 87

88 Trabalhando com Mercurial Ciclo de trabalho hg pull hg pull hg pull hg pull 88

89 Trabalhando com Mercurial Ciclo de trabalho hg pull hg pull hg pull hg pull hg push 89

90 Trabalhando com Mercurial Ciclo de trabalho hg import hg import hg import hg import hg export lista de s 90

91 Trabalhando com Mercurial Ciclo de trabalho Mercurial Subversion (distribuído) (centralizado) 1 * Remoto push pull Local 1 update commit update commit 1 * 91

92 Trabalhando com Mercurial Grafo de revisões tip 3: 3a63 2: ecf3 0: 9117 Bob Alice 1: 273c 92

93 Trabalhando com Mercurial Grafo de revisões tip tip 3: 3a63 3: 3a63 2: ecf3 2: ecf3 0: : 273c hg clone Bob Alice 1: 273c 0:

94 Trabalhando com Mercurial tip tip 5: 5f24 5: : ce3b 4: 207f 3: 3a63 3: 3a63 2: ecf3 2: ecf3 1: 273c 1: 273c 0: 9117 Bob Alice Grafo de revisões 0:

95 Trabalhando com Mercurial Grafo de revisões tip 7: 5f24 6: ce3b tip 5: 5f24 5: : ce3b 4: 207f 2: ecf3 3: 3a63 hg pull Bob Alice 3: 3a63 2: ecf3 95

96 Trabalhando com Mercurial Grafo de revisões merge hg merge tip 7: 5f24 tip 6: ce3b 5: 5f24 5: : ce3b 4: 207f 2: ecf3 3: 3a63 Bob Alice 3: 3a63 2: ecf3 96

97 Trabalhando com Mercurial Grafo de revisões tip 8: b4d0 7: 5f24 tip 6: ce3b 5: 5f24 5: : ce3b 4: 207f 2: ecf3 3: 3a63 Bob Alice 3: 3a63 2: ecf3 97

98 Trabalhando com Mercurial Grafo de revisões tip tip 8: b4d0 8: b4d0 7: : 5f24 6: 207f 6: ce3b 5: 5f24 5: : ce3b 4: 207f 2: ecf3 3: 3a63 Bob Alice 3: 3a63 hg pull (alice) hg push (bob) 2: ecf3 98

99 Trabalhando com Mercurial Comandos Comandos comuns hg hg hg hg hg hg hg hg hg hg hg hg add annotate commit copy diff help log remove rename revert status update (svn (svn (svn (svn (svn (svn (svn (svn (svn (svn (svn (svn add) blame) commit) copy) diff) help) log) delete) move) revert) status) update) 99

100 Trabalhando com Mercurial Comandos Acesso a repositórios Local HTTP, Mercurial SSH, Mercurial /home/user/hg/project/ file:///home/user/hg/project/ ssh://hg.example.com/hg/project/ 100

101 Trabalhando com Mercurial Criação e clonagem Criação do projeto hg init [diretório] Clonagem hg clone origem [diretório] Transforma o diretório atual (ou o diretório informado) em um repositório Mercurial Cria uma cópia do repositório de origem É, implicitamente, uma ramificação Hg lembra seu repositório de origem 101

102 Trabalhando com Mercurial Trabalho distribuído Trazer (puxar) submissões hg pull [URL] hg incoming [URL] Recupera as diferenças entre o repositório indicado e o seu, e aplica as alterações. Se URL for omitido, seu repositório de origem (fornecido ao hg clone ) é considerado. Atualiza apenas o repositório, use hg update para atualizar a cópia de trabalho. Mostra o que há no repositório indicado que não há no seu, e pode ser trazido com hg pull. 102

103 Trabalhando com Mercurial Trabalho distribuído Levar (empurrar) submissões hg push [URL] hg outgoing [URL] Determina as diferenças entre o seu repositório e o indicado, e as aplica remotamente. Se URL for omitido, seu repositório de origem (fornecido ao hg clone ) é considerado. Não cria ramificações remotas, seu repositório precisa estar compatível (via hg pull ). Mostra o que há no seu repositório que não há no indicado, e pode ser levado com hg push. 103

104 Trabalhando com Mercurial Trabalho distribuído Mescla hg heads [rev] hg merge [rev] Mostra as revisões-cabeça do grafo de revisões (todas as ramificações). Mescla as alterações de uma determinada cabeça à cópia de trabalho. Caso rev seja omitido, e só houver uma outra cabeça possível de ser mesclada (não ambígua), tal cabeça será selecionada. 104

105 Trabalhando com Mercurial Consulta de estado Comandos hg status hg identify [-i] [-n] [-b] [-t] Mostra qual a revisão atual da cópia de trabalho. hg parents [-r rev] [alvo] Mostra arquivos alterados, adicionados, etc. Mostra as revisões ascendentes da revisão atual (ou a revisão fornecida). 105

106 Trabalhando com Mercurial Consulta ao histórico Histórico hg log [-v] Visualização hg view Descrição textual do histórico. Visualiza o histórico interativamente. Grafo de revisões. 106

107 Trabalhando com Mercurial Ramificações Clonagem Locais, anônimas Criadas implicitamente Submissão sobre revisão intermediária Locais, explícitas Criadas implicitamente Basta clonar a cópia de trabalho Eficiente: utiliza hardlinks quando possível Criadas através de hg branch Armazenadas no próprio repositório 107

108 Trabalhando com Mercurial Rótulos Referenciam determinados changesets Fazem parte do controle de versões Comandos hg tag [-l] [-r rev] nome hg tag [-l] --remove nome Cria um novo rótulo nome para a revisão rev. Parâmetro -l : rótulo local. Apaga um rótulo. 108

109 Obrigado! Juliano F. Ravasi Esta apresentação: 109

110 Sistemas de Controle de Versão Juliano F. Ravasi Setembro / Sistemas de Controle de Versão (palestra mini-curso) Esta é uma palestra sobre sistemas de controle de versão, voltada em especial para o gerenciamento de software. Esta palestra é ministrada no formato de um mini-curso. Versão Copyright 2008 Juliano F. Ravasi Licensed under Creative Commons AttributionNoncommercial-Share Alike 2.5 Brazil License

111 Conteúdo Parte 1: Controle de Versões Parte 2: Trabalhando com Subversion Parte 3: Trabalhando com Mercurial 2 A palestra está dividida em três partes. Na primeira parte, dissertativa, é apresentado o conceito de controle de versões, desde sua motivação até seu uso voltado ao desenvolvimento de software. Na segunda parte, interativa, é apresentado o modelo centralizado de controle de versões, utilizando a ferramenta Subversion. Na terceira parte, interativa, é apresentado o modelo distribuído de controle de versões, utilizando a ferramenta Mercurial.

112 Controle de Versões Parte 1: Controle de Versões Motivação Recursos Conceitos Gerenciamento de software Fluxos de trabalho Sistemas de controle de versões O que armazenar? O que não armazenar? 3

113 Motivação O que é controle de versões? Gerenciamento de múltiplas revisões Documentos, projetos, software, etc. Histórico de alterações sofridas Permitir consultar revisões anteriores Permitir comparações entre revisões Permitir trabalho cooperativo 4 O controle de versões é o gerenciamento de múltiplas revisões de um documento, software, ou qualquer outro conjunto de informações que sofra alterações ao longo do tempo. O objetivo é manter um histórico das alterações realizadas, de forma a permitir consultar revisões anteriores, comparar diferentes revisões ou manter diferentes ramificações do projeto. O controle de versões também habilita o trabalho cooperativo de vários desenvolvedores sobre um mesmo projeto.

114 Motivação O que é controle de versões? Vários nomes: Revision control system (RCS) Version control system (VCS) Software Configuration Management (SCM) Source Code Management Source Control Controle de versão não é exclusivo para gerenciamento de software. 5 O controle de versões é conhecido por diversos nomes, mas geralmente os dois nomes mais comuns são Revision Control System ou Version Control System. Note que o primeiro, RCS, é também o nome de um antigo sistema de controle de versões, portanto VCS é preferido para evitar confusão. O nome Software Configuration Management as vezes é usado para o conceito de VCS, mas SCM é usado principalmente para um conceito mais abrangente, onde controle de versões é apenas uma das ferramentas envolvidas. Outros nomes menos usados incluem Source Code Management e Source Control, quando o controle de versões é empregado especificamente para o gerenciamento de software.

115 Motivação Por que controle de versões? Software é algo caro de ser produzido Consome muito tempo Exige cooperação, organização, disciplina É importante armazenar tudo que é feito 6 No nosso contexto, do gerenciamento de software, o controle de versões é uma ferramenta importante pois software é algo caro de ser produzido, em relação ao tempo que exige e o número de desenvolvedores que precisam ser empregados. Um único projeto de software pode envolver desde um único desenvolvedor até dezenas de milhares. O controle de versões é a ferramenta que permite essa maleabilidade no fluxo de desenvolvimento de um software.

116 Motivação Onde é utilizado? Sistemas de arquivos Suítes de escritório Ambientes colaborativos Gerenciamento de software Importante para qualquer desenvolvedor ou empresa de desenvolvimento de software. 7 O conceito de controle de versões foi empregado inicialmente em sistemas de arquivos, onde cada gravação de um arquivo fazia uma nova revisão ser registrada, mantendo o histórico de alterações de cada arquivo. Ainda hoje sistemas de arquivos são desenvolvidos com essa funcionalidade.

117 Motivação Onde é utilizado? 8 Em suites de escritório, programas como Microsoft Word ou Google Docs possuem recursos que habilitam diversos usuários registrar alterações em um único documento, sem perder o estado anterior. Dessa forma, duas ou mais pessoas trabalhando sobre o mesmo documento podem facilmente verificar as alterações feitas pelos outros participantes.

118 Motivação Onde é utilizado? 9 Em ambientes colaborativos, o conceito de revisões também possui grande importância, como em wikis. Especial notabilidade para a Wikipédia, a enciclopédia online de conteúdo livre que qualquer usuário pode editar. Toda alteração pode ser verificada pelos outros usuários, e estes podem reverter facilmente qualquer alteração não apropriada ao conteúdo.

119 Recursos Registro de revisões Toda alteração realizada é registrada Rápido acesso a revisões anteriores Quem, quando, o que e por quê? Nada é perdido para sempre Descartar código ruim sem remorso Determinar introdução de defeitos Manutenção de código legado 10 O principal recurso oferecido pelo controle de versões, é registro de revisões. Toda alteração feita sobre o documento ou projeto é registrada, com informações sobre quem fez a alteração, quando ocorreu, o que foi alterado, e por que a alteração foi feita. O desenvolvedor tem a liberdade de apagar ou reescrever qualquer parte do documento ou projeto, sem preocupações. Nada é perdido para sempre, e o desenvolvedor pode recuperar as revisões anteriores facilmente quando precisar. Essa característica de registro histórico ou máquina do tempo permite determinar quando defeitos foram introduzidos, ou manter código legado de um software.

120 Recursos Auditoria Comparação entre versões do projeto, mostrando diferenças linha-a-linha Apontar desenvolvedores responsáveis por cada trecho de código do projeto Automação de testes de estabilidade 11 Agregado ao registro histórico de revisões surge outra característica importante: a auditoria do projeto. O sistema de controle de versões integra ferramentas que permitem, por exemplo, comparar cada linha de duas diferentes revisões de um único arquivo, apontando quais trechos foram alterados. Ou ainda, mostrar qual desenvolvedor é responsável pela última alteração em determinada linha do arquivo. O sistema de controle de versões pode ser integrado a uma plataforma de testes que garanta a estabilidade do projeto. Por exemplo, não permitir que os desenvolvedores registrem alterações que façam o programa falhar numa suíte de testes.

121 Recursos Ramificações Múltiplas linhas de desenvolvimento dentro do mesmo projeto Permite divergência e reconvergência do desenvolvimento 12 Mais uma característica importante do controle de versões é permitir que o projeto se ramifique em múltiplas linhas de desenvolvimento, que seguem em paralelo e possuem um passado comum. Estas ramificações podem depois reconvergir novamente em uma única linha de desenvolvimento.

122 Recursos Trabalho cooperativo Vários desenvolvedores trabalhando sobre o mesmo projeto Mescla das alterações dos diversos desenvolvedores ou ramificações 13 O controle de versões habilita o trabalho cooperativo, de forma que vários desenvolvedores possam trabalhar sobre o mesmo conjunto de arquivos. Cada desenvolvedor trabalhando simultaneamente sobre o mesmo projeto acaba por criar pequenas ramificações (implícitas), que são periodicamente reintegradas (ou mescladas) ao projeto.

123 Recursos Segurança Autenticação criptográfica de histórico Controle de acesso sobre o repositório Cópias de segurança (backup) 14 Por fim, o controle de versões habilita alguns aspectos de segurança para o projeto. Os recursos disponíveis e a forma como são implementados variam bastante entre diferentes ferramentas. Algumas ferramentas permitem autenticar de forma criptográfica o histórico das alterações ocorridas no projeto. Outra forma de segurança é controlar quem acessa o repositório que o projeto está armazenado, e quais partes do projeto cada desenvolvedor pode acessar. Por fim, o controle de versões habilita diferentes formas de manter cópias de segurança do projeto.

124 Modelos Centralizado (cliente-servidor) Distribuído Um repositório central de revisões Desenvolvedores obtém cópias de trabalho do repositório central Cada desenvolvedor tem seu repositório Desenvolvedores copiam repositórios e alterações de outros desenvolvedores 15 Há dois modelos fundamentalmente diferentes de controle de versões em uso hoje. O modelo centralizado, também conhecido como cliente-servidor, já vem sendo utilizado desde a década de Nesse modelo, as revisões do projeto são armazenadas em um repositório central, onde os desenvolvedores obtém suas cópias de trabalho, e para onde submetem suas alterações. O modelo distribuído, por sua vez, vem sendo popularizado há cerca de uma década. Nesse modelo, cada desenvolvedor possui seu próprio repositório local, que armazena parte ou todas as alterações desde o início do projeto. As alterações são replicadas entre os diversos repositórios. Cada modelo possui vantagens e desvantagens.

125 Modelos Centralizado (cliente-servidor) Vantagens: Desvantagens: Controle de acesso Cópia de segurança Controle de qualidade Dependência do repositório central Ponto único de falha 16 O modelo centralizado permite um melhor controle de quais desenvolvedores acessam quais partes do projeto. Como todos os desenvolvedores desenvolvem sobre o mesmo repositório, as cópias de segurança são mais simples: um único repositório precisa ser armazenado. O controle de qualidade pode ser implementado mais facilmente, através da monitoração e testes automatizados das alterações do projeto. Por outro lado, no modelo centralizado, os desenvolvedores ficam atados ao repositório central, o que pode ser inconveniente durante momentos em que o desenvolvedor não possui acesso a ele (durante uma viagem). É também um ponto único de falha, sua falta pode atrapalhar toda a equipe de desenvolvedores.

126 Modelos Distribuído Vantagens: Desvantagens: Permite submissões particulares, offline Melhor suporte a ramificação e mescla Independência da rede, mais rápido Estimula o isolamento de desenvolvedores Questões de privacidade e segurança 17 O modelo distribuído habilita cada desenvolvedor a ter seu repositório particular, onde suas alterações são registradas antes de serem compartilhadas com outros desenvolvedores. Como ramificações e mesclas ocorrem o tempo todo, VCSes distribuídos tendem a ter um suporte muito bom para essa finalidade. Operações de consulta ao histórico não dependem da rede, portanto muito mais rápidas. Por outro lado, desenvolvedores tentem a se isolar, inibindo a revisão e auditoria do resto da equipe. Soltar uma bomba no momento de reintegrar o desenvolvimento. Para empresas de desenvolvimento de software proprietário, a idéia de um desenvolvedor carregar uma cópia completa do repositório em um laptop, por exemplo, é assustadora.

127 Modelos Centralizado vs. distribuído Assunto quente nos últimos anos Há sobreposição entre os modelos Ferramentas distribuídas podem ser usadas no modelo centralizado, quando necessário Ainda não existe a ferramenta perfeita Opiniões inflamadas, guerra de egos Cada modelo de desenvolvimento exige um modelo de controle de versões 18 Controle de versões distribuído é um conceito novo, seus proponentes tendem a causar guerras de egos ao dizer que sistemas centralizados são inferiores ou obsoletos. Por outro lado, sistemas centralizados ainda são dominantes em número de usuários e ferramentas disponíveis. O número de ferramentas distribuídas atrapalha a popularização do modelo. Ferramentas distribuídas podem ser usadas de forma centralizada, mas a simplicidade das ferramentas centralizadas parecem influenciar na escolha quando projetos não precisam ser distribuídos. Não há uma única resposta para todas as perguntas, não há calça que sirva a todos, não há uma única ferramenta perfeita que atenda à todas as necessidades.

128 Conceitos Repositório Núcleo do controle de versões Possui uma linha do tempo embutida Coletânea de revisões do projeto 19 O repositório é o componente principal do sistema de controle de versões. É o seu núcleo, e é composto por uma seqüência de revisões armazenadas ao longo do tempo. Em geral, o usuário só interage diretamente com o repositório durante operações de leitura. A escrita no repositório é realizada por intermédio de outro componente: a cópia de trabalho.

129 Conceitos Repositório Revisão Estado em um determinado instante Imutável após criada 20 Cada revisão do repositório representa o estado completo do documento ou projeto em um determinado instante no tempo. Para softwares, isso significa que uma revisão contém toda a árvore de diretórios e os arquivos no estado em que se encontravam naquele momento. Sistemas antigos, até o CVS, utilizavam revisões independentes para cada arquivo. Hoje esse modelo é obsoleto, em favor dos changesets. Após criadas, revisões são imutáveis, pois fazem parte do histórico do projeto. Algumas ferramentas permitem alterar ou remover revisões antigas, mas não é um procedimento natural do VCS. Cada revisão está ligada à sua revisão diretamente ancestral, e geralmente é armazenada na forma de um delta.

130 Conceitos Cópia de trabalho Cópia do repositório em certa revisão Geralmente a mais recente Checkout (obtenção de uma cópia) 21 A cópia de trabalho é uma cópia usável do projeto contido no repositório, em uma determinada revisão. Por padrão, obtém-se uma cópia de trabalho da última revisão, pois é sobre ela que o desenvolvedor prossegue com o desenvolvimento do projeto. O processo de obtenção de uma cópia de trabalho é chamada de checkout.

131 Conceitos Cópia de trabalho Onde ocorre o desenvolvimento O sistema reconhece as alterações feitas Algumas operações devem ser explícitas Adição, remoção, moção e cópia de arquivos 22 Sobre a cópia de trabalho o desenvolvedor realiza as modificações no projeto, de forma semelhante a como faria sem o sistema de controle de versões. O sistema conhece o estado da cópia de trabalho pristina, e através dela é possível reconhecer onde foram realizadas alterações. Algumas operações precisam ser informadas explicitamente ao sistema de controle de versões, como adição, remoção, moção e cópia de arquivos.

132 Conceitos Cópia de trabalho Submissão (commit) Alterações são registradas em uma nova revisão do repositório 23 A submissão, ou commit, consiste em registrar o estado atual da cópia de trabalho, com suas alterações, devolta ao repositório. Uma nova revisão é criada como resultado da submissão. Após a submissão, a cópia de trabalho já é considerada como sendo derivada da nova revisão, e o desenvolvedor pode continuar fazendo novas alterações e novas submissões normalmente.

133 Conceitos Ramificações (branches) Linhas alternativas de desenvolvimento Explícitas Implícitas 24 Ramificações ocorrem quando por um motivo qualquer, o desenvolvimento do projeto em uma determinada revisão precisa seguir um rumo diferente da linha de desenvolvimento principal. Quando uma ramificação ocorre, duas ou mais revisões possuem uma única revisão ancestral. O desenvolvedor pode, portanto, submeter alterações para qualquer uma das revisões. Ramificações podem ser explícitas ou implícitas.

134 Conceitos Ramificações (branches) Explícitas Manutenção de versões legadas Implementação de novos recursos Experiências no código do projeto 25 Ramificações explícitas ocorrem quando você informa ao sistema de controle de versões para bifurcar a linha de desenvolvimento em determinado ponto. Isso é útil para manter versões legadas de software (por exemplo, lançar uma versão 1.1 do programa com uma pequena correção em relação à versão 1.0, enquanto o desenvolvimento principal segue em direção à versão 2.0); implementar novos recursos que podem causar períodos de instabilidade no código; ou fazer experiências sem afetar a linha principal de desenvolvimento.

135 Conceitos Ramificações (branches) Implícitas Cópia de trabalho Múltiplos desenvolvedores 26 Ramificações implícitas ocorrem quando o desenvolvimento se ramifica de uma forma natural, sem um procedimento especial junto ao controle de versões. Por exemplo, dois ou mais desenvolvedores obtém cópias de trabalho da mesma última revisão do repositório, e fazem alterações em suas cópias simultaneamente. Nesse caso, cada cópia de trabalho representa uma ramificação implícita, que o controle de versões não participa até o momento da submissão.

136 Conceitos Mescla (merge) Reintegração de ramificações Em grande parte é automatizado Conflitos podem ocorrer O desenvolvedor pode precisar interagir 27 A grande utilidade das ramificações depende da capacidade de poder reintegrar suas alterações devolta à linha de desenvolvimento principal. Essa operação é chamada de mescla. Em grande parte, o controle de versões automatiza essa tarefa de forma (quase) indolor. Mas podem ocorrer conflitos, em especial se dois desenvolvedores alterarem o mesmo trecho do mesmo arquivo. Quando um conflito ocorre, a operação de mescla, submissão ou atualização falha, e o controle de versões pede ao desenvolvedor para resolver o conflito. A capacidade de realizar mesclas de forma eficiente e provadamente correta é um fator que diferencia os vários sistemas de controle de versões.

137 Conceitos Rótulos (tags) Nomes atribuídos a revisões 28 Rótulos são nomes que o usuário do sistema de controle de versões pode atribuir a revisões específicas do controle de versões. Esses nomes facilitam a consulta e a navegação pelo histórico do projeto.

138 Gerenciamento de software Fluxos de trabalho Solitário Centralizado Distribuído Repositório local Repositório remoto Parceiro Equipe Hierárquico 29 O controle de versões habilita diferentes formas de trabalho sobre um projeto de software. Apesar de ser possível usar qualquer modelo de controle de versões com qualquer fluxo de trabalho, naturalmente, um controle de versões centralizado é mais limitado a fluxos de trabalho centralizados enquanto que controle de versões distribuído é mais adequado a fluxos de trabalho distribuídos.

139 Gerenciamento de software Fluxos de trabalho Solitário 30 Quase todo o projeto de software começa com um único desenvolvedor em uma única estação de trabalho. Nesse caso, só um repositório e só uma cópia de trabalho são necessários, portanto, ambos os modelos centralizado e distribuído podem ser utilizados.

140 Gerenciamento de software Fluxos de trabalho Centralizado, repositório local 31 Durante as décadas de 1970 e 1980, quando ainda existiam mais pessoas do que computadores, era uma situação comum vários desenvolvedores trabalharem juntos ao mesmo computador. Nesse caso, um único repositório é armazenado localmente, e acessado por mais de um usuário local. Quando um segundo desenvolvedor se une ao projeto, a este é dado acesso ao sistema que contém o repositório.

141 Gerenciamento de software Fluxos de trabalho Centralizado, repositório remoto 32 Contudo, nos tempos atuais é comum uma única pessoa possuir diversos computadores. Redes de computadores interligam esses computadores de forma quase ubíqua. Nessa situação, o modelo centralizado exige que um repositório central seja armazenado em um computador dedicado, e cada desenvolvedor obtém uma cópia de trabalho em seu computador pessoal para desenvolver.

142 Gerenciamento de software Fluxos de trabalho Distribuído, parceiro 33 Outro rumo possível quando um segundo desenvolvedor se une a um projeto inicialmente solitário é o uso do modelo distribuído. Nesse caso, não é necessário de um repositório central. Enquanto apenas dois desenvolvedores participarem do projeto, só há um caminho para as alterações de cada desenvolvedor.

143 Gerenciamento de software Fluxos de trabalho Distribuído, equipe 34 Quando o número de desenvolvedores cresce, o compartilhamento das alterações pode se tornar um problema. Nesse caso, é comum eleger um desenvolvedor que será o ponto-de-referência para os outros desenvolvedores. É possível também incluir no fluxo de trabalho um servidor dedicado a compartilhar as alterações entre os desenvolvedores, fazendo assim o controle de versões distribuído assumir algumas características de centralizado.

144 Gerenciamento de software Fluxos de trabalho Distribuído, hierárquico 35 Por fim, o fluxo hierárquico, onde um desenvolvedor fica no topo de uma hierarquia onde gerencia o projeto. Esse desenvolvedor também pode ter acesso exclusivo a um servidor onde os outros participantes podem obter as alterações. Geralmente, há dois ou três níveis de hierarquia. Estes não são os únicos fluxos de trabalho possíveis, qualquer variação pode ser inventada para atender às necessidades de cada projeto. Controles de versões distribuídos oferecem maior flexibilidade para atender uma maior variedade de fluxos de trabalho.

145 Gerenciamento de software Sistemas de controle de versões SourceAnyware Vault Git darcs MOG ArX Surround FtpVC PlasticSCM CVS Store Stellation ClearCase Vesta AllFusion codebeamer Perforce SourceSafe DCVS GNU arch CodeVille Aegis PureCM Mercurial RCS Team Foundation Server FirePublish Team Coherence SourceHaven MKS QVCS Fossil TeamWare Code Co-op AccuRev Evolution DesignSync SVK Serena FileHamster Aldon AVS CVSNT Subversion OpenCVS LibreSource AlienBrain StarTeam BitKeeper Synergy Monotone Bazaar 36 Uma característica boa dos sistemas de controle de versões é que há muitos deles para você escolher. Uma característica ruim dos sistemas de controle de versões é que há muitos deles para você escolher.

146 Gerenciamento de software Sistemas de controle de versões Centralizado Aegis CVSNT CVS Aberto Distribuído OpenCVS CodeVille Stellation Subversion ArX arch Fossil Vesta darcs Git Bazaar DCVS LibreSource Mercurial Monotone SVK AccuRev Aldon AlienBrain AllFusion Proprietário AVS ClearCase codebeamer DesignSync Evolution FileHamster FirePublish Perforce FtpVC MKS PureCM QVCS SourceAnyware SourceSafe Code Co-op MOG Serena SourceHaven StarTeam BitKeeper TeamWare Store Surround Synergy Team Coherence Vault PlasticSCM Team Foundation Server 37 Fica mais fácil escolher se os classificarmos em sistemas centralizados e distribuídos, e em abertos e proprietários. Não é interesse dessa palestra falar sobre sistemas proprietários. Então deixamos essa tarefa aos seus respectivos consultores de marketing. Isso nos deixa com um número bem menor de sistemas de interesse para fazer uma visão geral, mas ainda muitos para o pouco tempo.

147 Gerenciamento de software Sistemas de controle de versões Visão geral dos VCSs abertos: Centralizados: Git Mercurial Bazaar Mais: Distribuídos: CVS Subversion Dessa forma, foram eleitos cinco sistemas considerados os mais populares hoje (setembro de 2008) pelo palestrante para uma visão geral, dois centralizados (CVS e Subversion) e três distribuídos (Git, Mercurial e Bazaar). O palestrante reconhece que vários outros controles de versões distribuídos mereciam uma menção, pois contribuíram indiretamente para o avanço dessa nova ciência, mas é necessário dar um foco mais prático para não estender demais a apresentação. Destes, dois sistemas, Subversion e Mercurial, foram escolhidos como representantes de suas categorias para uma demonstração prática do uso de controle de versões.

148 Sistemas de controle de versão CVS Criado para substituir o RCS (1980s) Obsoleto, desenvolvimento estagnado Modelo centralizado Possui grande base de usuários Possui defeitos e limitações de projeto Escrito em C, monolítico 39 CVS (Concurrent Versions System), apesar de antigo e largamente considerado obsoleto, ainda é muito utilizado, especialmente em projetos que existem desde quando essa era a única opção viável. Foi desenvolvido na década de 1990, para substituir o RCS, da década de Possui inúmeros defeitos e limitações de projeto. Muitos desenvolvedores acreditam que usar CVS causa mais dor e sofrimento do que não usar qualquer controle de versões.

149 Sistemas de controle de versão Subversion Sucessor do CVS Projetado para contornar os seus defeitos Desenvolvido por CollabNet Inc. Modelo centralizado Robusto e maduro Ênfase em qualidade, larga escala Sem restrições a tipos de arquivos Escrito em C, modular 40 Subversion é considerado o sucessor do CVS, projetado especificamente para contornar seus defeitos. Possui inúmeras inovações, e grandes diferenças em relação ao CVS. É hoje o sistema de controle de versões centralizado mais adotado para novos projetos. Possui um projeto sólido, robusto e maduro. Seu desenvolvimento dá ênfase à qualidade e ao uso em larga escala. Não impõe restrições quanto aos tipos de arquivos, gerenciando arquivos binários tão bem quanto arquivos texto, além de reconhecer diretórios. Multiplataforma, suporta Windows nativamente.

150 Sistemas de controle de versão Subversion Projeto em camadas Repositório Acesso ao repositório Bindings: C, Python, Perl, Java, Ruby Cliente Local, WebDAV, svnserve Cópia de trabalho Biblioteca de cliente BorlandDB, fsfs svn, TortoiseSVN, Subclipse, KDESvn, Trac, Subversion possui um projeto em camadas, o que acrescenta à robustez da ferramenta. Repositório, acesso ao repositório, cópia de trabalho, biblioteca de cliente e o cliente são todos módulos semiindependentes que se comunicam através de uma API bem definida e documentada.

151 Sistemas de controle de versão Git Criado para gerenciar o kernel do Linux Após controvérsia sobre o BitKeeper Inspirado no Monotone Inicialmente por Linus Torvalds Modelo distribuído Ênfase em desenvolvimento não-linear Autenticação criptográfica do histórico Gerencia conteúdo, ao invés de arquivos Escrito em C, monolítico 42 Git é um sistema de controle de versões escrito inicialmente por Linus Torvalds, especificamente para gerenciar o kernel do Linux. Segue o modelo distribuído, com uma grande ênfase em desenvolvimento não-linear. Oferece autenticação criptográfica do histórico e possui alto desempenho para as operações mais comuns. Utiliza um paradigma diferente: gerencia o conteúdo dos arquivos, deixando os arquivos em si como entidades secundárias. Possui uma curva de aprendizado íngreme, impõe alguns conceitos complexos e confusos. É considerado difícil de usar, apesar dos avanços em usabilidade à partir da versão 1.5. Suporte à plataforma Windows é secundário e limitado.

152 Sistemas de controle de versão Mercurial Criado simultaneamente ao Git Inspirado no Monotone Desenvolvido por Matt Mackall Modelo distribuído Autenticação criptográfica do histórico Ênfase em uso por grandes projetos Escrito em Python, modular 43 Mercurial foi criado simultaneamente ao Git, com os propósitos semelhantes, por Matt Mackall. Como o Git, segue o modelo distribuído e oferece autenticação criptográfica do histórico. Ao contrário do Git, não foi projetado para atender apenas ao desenvolvimento do kernel do Linux, mas para ser usado por grandes projetos. Possui um bom desempenho, graças a um projeto de repositório muito eficiente. É considerado bem simples de usar, e possui um conjunto de comandos familiar para usuários de Subversion. É portável e bem suportado na plataforma Windows.

153 Sistemas de controle de versão Bazaar Desenvolvido por Canonical Inc. Modelo distribuído Ênfase em facilidade, flexibilidade Suporte a múltiplos fluxos de trabalho Desempenho ruim Escrito em Python, modular 44 Bazaar foi desenvolvido pela Canonical Inc. com diversas finalidades em mente, entre elas facilidade, flexibilidade e suporte a fluxos de trabalho centralizados e distribuídos. Possui longa história de ancestrais: GNU arch, tla, baz, Bazaar-NG. É usado para gerenciar softwares da distribuição Ubuntu. Oferece um bom suporte à plataforma Windows, e é considerado bem fácil de usar. Infelizmente, possui (possuia) sérios problemas de desempenho. Foi desclassificado na seleção de dois grandes projetos (Mozilla e OpenSolaris) devido ao seu péssimo desempenho.