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.

154 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 O controle de versões armazena apenas os arquivos explicitamente indicados pelo desenvolvedor. Nem todos os arquivos são adequados a serem armazenados no controle de versões. Em geral, apenas os arquivos que foram produzidos manualmente pelo desenvolvedor devem ser armazenados. Isso inclui: código fonte, scripts de automação, documentação escrita, figuras, imagens, e ícones, e makefiles.

155 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 Não se deve armazenar no controle de versões aqueles arquivos que são gerados por processos automáticos, como compilação ou conversão de arquivos fonte. Isso inclui: código-objeto, programas compilados e documentação automática (JavaDoc, Doxygen, etc). Também não se deve armazenar arquivos de configurações locais ou que deverão ser alterados pelo usuário final para executar a aplicação, ou arquivos criados acidentalmente.

156 Trabalhando com Subversion Parte 2: Trabalhando com Subversion Características gerais Repositório Ciclo de trabalho Comandos Consulta de histórico (svn log) Atualização (svn update) Comparação (svn diff) Consulta de estado (svn status) Ramificações Mescla e reversão Rótulos Propriedades 47

157 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 Por ser um controle de versões centralizado, o Subversion armazena o repositório e a cópia de trabalho em lugares distintos. O mesmo repositório é usado por todas as cópias de trabalho. Ramificações e rótulos são gerenciados de forma implícita, como parte da árvore do repositório. São criados através de cópias do diretório do projeto (tronco) para outros diretórios. O Subversion faz cópias leves, que não consomem espaço adicional. A distinção entre tronco, ramificações e rótulos é feita pelo usuário. Algumas das características únicas do Subversion são: suporte a propriedades, controle de diretórios e WebDAV.

158 Trabalhando com Subversion Características gerais Recomendação Usar versão 1.5 ou superior. Informações Projeto: Manual: Clientes: Windows: Eclipse: KDE: 49 A versão 1.5 do Subversion implementa diversos novos recursos, em especial o suporte mais avançado a mesclas. O manual do Subversion é leitura obrigatória a todos os usuários. Todas as informações necessárias para o uso da ferramenta podem ser encontradas no manual.

159 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 O repositório Subversion é um sistema de arquivos baseado em ligações, onde cada revisão aumenta ao tamanho do repositório apenas as alterações em relação à revisão anterior. Cópias de arquivos e diretórios dentro do repositório são leves, rápidas e não consomem espaço adicional. O repositório é implementado na forma de um banco-de-dados transacional: ou a nova revisão ocorre por completo, ou ela simplesmente não ocorre. Cada revisão no repositório é identificada por um número seqüencial, onde a primeira revisão, com o repositório vazio, é a revisão zero. O repositório pode ser organizado de acordo com as necessidades do usuário. Uma boa sugestão é armazenar um projeto (incluindo possíveis subprojetos) para cada repositório.

160 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 Para se criar um novo repositório Subversion, utilizase o comando svnadmin. O repositório é armazenado sob uma árvore de diretórios no sistema de arquivos do usuário. Qualquer pessoa com acesso de leitura (e escrita) a este diretório pode recuperar seu conteúdo (e gravar novas revisões). «Demonstração: criação do repositório» Dentro do repositório, é necessário criar divisões para organizar o projeto. É importante adotar uma convenção de hierarquia que separará o tronco do desenvolvimento das ramificações e dos rótulos.

161 Trabalhando com Subversion Repositório Convenções de hierarquia 52 A hierarquia do repositório pode variar de acordo com as necessidades do usuário. No primeiro exemplo, apenas um projeto é armazenado no repositório, em trunk, com ramificações armazenadas em branches e rótulos armazenados em tags. No segundo exemplo, o projeto é composto por vários subprojetos. No primeiro nível de diretórios sob a raiz estão os diretórios para tronco, ramificações e rótulos, e no segundo nível há divisões para cada projeto. No terceiro exemplo, o projeto também é composto por vários subprojetos, mas cada projeto é colocado no primeiro nível de diretórios sob a raiz, cada um com seus diretórios de tronco, ramificações e rótulos.

162 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 Ao ser criado, o repositório estará vazio, na revisão zero. Antes de começar a usar o repositório, é uma boa idéia criar a hierarquia de diretórios do repositório. Nesse caso vamos criamos uma estrutura simples para um único projeto. Isso é feito obtendo uma cópia de trabalho da raiz do repositório (svn checkout), criando os diretórios (svn mkdir), e submetendo a primeira revisão do projeto devolta ao repositório (svn commit). Após isso podemos descartar essa cópia de trabalho. Uma segunda alternativa é criar a hierarquia de diretórios diretamente sobre o repositório, passando as URLs completas para o comando svn mkdir. Aqui é mostrado também uma simplificação do comando usando recursos do shell. «Demonstração: hierarquia inicial»

163 Trabalhando com Subversion Ciclo de trabalho 1. Obtenção (checkout) svn checkout ❶ svn checkout 54 O ciclo básico de trabalho com o Subversion é composto de cinco passos. Primeiramente, obtém-se uma cópia de trabalho local do repositório através do comando svn checkout. A cópia local contém toda a hierarquia de arquivos e diretórios da última revisão (opcionalmente: uma determinada revisão) do projeto no repositório no endereço fornecido. A cópia de trabalho mantém, além dos arquivos do projeto, informações sobre o estado do projeto, a revisão obtida e o caminho do repositório.

164 Trabalhando com Subversion Ciclo de trabalho 2. Desenvolvimento ❷ (edição) 55 Após obter uma cópia de trabalho do projeto, o usuário desenvolve sobre este da forma como faz usualmente. Não é necessário se comunicar com o repositório durante o desenvolvimento.

165 Trabalhando com Subversion Ciclo de trabalho 3. Comparação, reversão svn status svn diff svn revert ❸ svn diff svn revert 56 Após alterar os arquivos da cópia de trabalho, esta terá seu estado marcado como alterada. Isso significa que há alterações locais que não estão armazenadas no repositório ainda. O usuário pode consultar as alterações feitas ao projeto, e opcionalmente reverter quaisquer alterações incorretas. Esses procedimentos não fazem acesso ao repositório.

166 Trabalhando com Subversion Ciclo de trabalho 4. Submissão svn commit ❹ svn commit 57 Quando o desenvolvedor achar que suas alterações estão adequadas, este as submete devolta ao repositório. Ao submeter ao repositório, uma nova revisão é criada, e a cópia de trabalho é atualizada para a nova revisão, e também seu estado se torna limpo, ou seja, a cópia de trabalho mais uma vez volta a representar a última revisão do projeto no repositório.

167 Trabalhando com Subversion Ciclo de trabalho 5. Atualização svn update ❺ svn update 58 Outros desenvolvedores utilizando o mesmo repositório podem também ter submetido suas alterações. O usuário pode receber essas alterações em sua cópia de trabalho fazendo uma atualização. Durante o desenvolvimento paralelo, é possível que seja necessário atualizar a cópia de trabalho antes de submeter ao repositório. Nesse processo podem ocorrer conflitos entre as alterações locais e as alterações realizadas pelos outros desenvolvedores.

168 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 O Subversion fornece alguns programas executáveis que o desenvolvedor utiliza para interagir com a cópia de trabalho e o repositório. Os principais comandos são o cliente padrão, svn, e a ferramenta de manutenção do repositório, svnadmin. Outros ferramentas são fornecidas, mas são de importância secundária.

169 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/ O repositório pode ser acessado de pelo menos quatro formas diferentes (outras formas podem ser criadas pelo usuário). Cada forma de acesso é representada pelo esquema do endereço passado para os comandos. Para acesso a um repositório local, hospedado na mesma máquina, é utilizado o esquema file://. Repositórios remotos podem ser acessados via HTTP, através do protocolo WebDAV, via um protocolo próprio (svnserve), ou via SSH se o usuário possuir um login shell no servidor remoto.

170 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 É possível trabalhar apenas sobre uma parte do projeto, fornecendo o caminho completo do diretório desejado ao comando svn. Na verdade, normalmente se obtém apenas o diretório trunk do projeto que você quer trabalhar.

171 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 É possível importar um projeto pré-existente diretamente para o repositório, através do comando svn import. Para se obter uma cópia de trabalho, utiliza-se o comando svn checkout, fornecendo o endereço do projeto no repositório e (opcionalmente) o diretório para onde será copiado. Por padrão, a última revisão do projeto é obtida. O comando svn export é semelhante ao checkout, exceto que a cópia obtida é limpa, sem controle de versões (adequada para empacotamento). O comando svn update é utilizado para atualizar uma cópia de trabalho já existente para a última revisão armazenada no repositório. «Demonstração: obtenção da cópia de trabalho»

172 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 A edição de arquivos pode ser feita livremente sobre os arquivos da cópia de trabalho. Subversion reconhece as alterações automaticamente. Contudo, para outras operações, como adicionar, remover, copiar ou mover arquivos, é necessário informar explicitamente. «Demonstração: edição, adição, remoção»

173 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 Após a edição, verifica-se quais alterações foram reconhecidas pelo Subversion (e portanto serão submetidas ao repositório mais adiante). É possível também reverter alterações acidentais. «Demonstração: consulta, reversão»

174 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 Antes de submeter, podemos atualizar a cópia de trabalho novamente, para obter as alterações realizadas por outros desenvolvedores enquanto estávamos a realizar as nossas. Isso garante que o repositório irá aceitar nossa submissão, pois ela irá adicionar de forma limpa ao final da linha de revisões. Por fim, registramos nossas alterações submetendo ao repositório. Podemos submeter todas as alterações como uma única revisão, ou seletivamente partes da cópia de trabalho, repetindo o comando diversas vezes (criando diversas revisões separadas). «Demonstração: submissão»

175 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 Se durante a nossa edição, outro desenvolvedor submeter alterações para os mesmos arquivos, ocorrerá colisões. O Subversion irá se esforçar para mesclar automaticamente as alterações para nós, mas se ocorreram alterações na mesma região de algum arquivo, um conflito ocorrerá. Nesse caso, o Subversion irá solicitar a mescla manual do conflito. Após resolver o conflito, informamos que a resolução foi concluída, e então será possível continuar com a submissão. «Demonstração: resolução de conflitos»

176 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 O grande poder de um VCS é a capacidade de rever e analisar o histórico passado do projeto. O Subversion oferece diversos comandos para essa finalidade. «Demonstração: informações e auditoria»

177 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 O comando svn log mostra o histórico de revisões do projeto, das revisões mais recentes para as mais antigas (por padrão). Para cada revisão, são listadas suas informações fundamentais: quem, quando e o que foi alterado, e por que a alteração foi feita.

178 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 O comando svn update pode ser utilizado para visitar revisões anteriores do projeto. Para isso, basta fornecer o número da revisão ou a data para a qual se deseja viajar. Note que não é possível submeter alterações para revisões antigas, a menos que se crie ramificações para isso. Para retornar à revisão mais atual, basta utilizar svn update sem argumentos. «Demonstração: viagem no histórico»

179 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 O comando svn diff é utilizado para comparar arquivos, tanto em relação às alterações ocorridas na cópia de trabalho (que ainda não foram submetidas), quanto em relação às alterações ocorridas entre duas revisões quaisquer do projeto. «Demonstração: comparação»

180 Trabalhando com Subversion Comparação (svn diff) 71 A saída do comando svn diff é a mesma do comando Unix padrão diff, no formato unificado. Nesse formato, cada arquivo alterado é relatado por alguns cabeçalhos, seguido dos trechos que foram alterados. Para cada trecho, linhas removidas são denotadas com o caractere -, e linhas adicionadas são denotadas com o caractere +. A saída do comando pode ser gravada em um arquivo, e subseqüentemente passada para o comando patch, que é capaz de refazer ou desfazer as alterações indicadas automaticamente, dado um conjunto de arquivos compatível. A saída também pode ser enviada para outras ferramentas que ajudam a visualização das alterações (ex: diffstat, kompare).

181 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 O comando svn status mostra o estado atual da cópia de trabalho em relação à revisão base, um resumo das alterações realizadas na cópia de trabalho. A arquivo que não esteja no seu estado limpo é listado, acompanhado de indicadores do estado do arquivo em relação à sua referência na revisão base do repositório.

182 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 No Subversion, ramificações são criadas criando-se cópias do tronco ou de outras ramificações. O comando svn copy, nesse caso, é usado diretamente sobre o repositório, e portanto, causa a criação de uma nova revisão. A cópia de trabalho pode alternar de uma ramificação para outra através do comando svn switch, passando-se o endereço completo da ramificação para a qual deseja-se alternar. «Demonstração: ramificações»

183 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 As ramificações divergem o desenvolvimento do projeto em diferentes direções. Ramificações de recursos devem se manter em dia com o desenvolvimento principal, e devem em dado momento ser reintegradas ao tronco do projeto. O comando svn merge mescla as alterações da ramificação indicada à cópia de trabalho (para serem testadas e então submetidas como parte da ramificação corrente). É possível mesclar automaticamente todas as revisões pendentes (desde a ramificação ou a última mescla), ou selecionar determinadas revisões. Para ramificações de recursos, estas devem ser reintegradas à linha de desenvolvimento originária através de um parâmetro especial. «Demonstração: mescla»

184 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 O comando svn merge também pode ser utilizado para reverter uma revisão anteriormente submetida (que pode, por exemplo, ter introduzido um bug ao projeto). O princípio é exatamente o mesmo da mescla comum, só que aplicado de forma inversa (negativa) e geralmente dentro da mesma ramificação.

185 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 Rótulos são criados da mesma forma que as ramificações, mas em um diretório diferente do repositório. A diferença entre ramificações e rótulos para o Subversion é estritamente semântica, e aplicada pelo usuário. Convenciona-se que o diretório /tags/ do repositório deve receber apenas rótulos. O administrador do repositório Subversion pode criar algumas regras que protegem o diretório /tags/ de submissões acidentais. «Demonstração: rótulos»

186 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 Um recurso único do Subversion é o suporte a propriedades. Propriedades são tuplas (chave, valor) que podem ser associadas a objetos (diretórios e arquivos) ou revisões. Propriedades oferecem uma forma elegante de armazenar informações adicionais sobre objetos. Elas são utilizadas primariamente para armazenar informações do controle de versões, mas podem ser utilizadas pelo usuário para armazenar outras meta-informações que achar conveniente.

187 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 Propriedades são usadas, por exemplo, para definir quais arquivos não devem ser monitorados pelo controle de versões (svn:ignore), realizar conversões especiais no conteúdo dos arquivos (svn:eol-style, svn:keywords), ou importar diversos projetos distintos em uma única hierarquia (svn:externals).

188 Trabalhando com Mercurial Parte 3: Trabalhando com Mercurial Características gerais Repositório Ciclo de trabalho Grafo de revisões Comandos Criação e clonagem Trabalho distribuído Ramificações Rótulos 79

189 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 Mercurial é um sistema de controle de versões distribuído, projetado especificamente para gerenciamento de software. Portanto, cada desenvolvedor ou usuário deve ter sua cópia local do repositório. O repositório local é armazenado juntamente à cópia de trabalho, para a conveniência do usuário. Ao contrário do Subversion, ramificações e rótulos são objetos gerenciados explicitamente pelo controle de versões, com comandos dedicados. Cada cópia de trabalho (que inclui o repositório) é automaticamente uma ramificação implícita do projeto.

190 Trabalhando com Mercurial Características gerais Informações Projeto: Manual: Clientes: Windows: Eclipse: 81 A versão atual (em Set/2008) do Mercurial é A página do projeto contém uma grande quantidade de informações úteis, incluindo tutoriais e guias de referência. O manual (hgbook) está ligeiramente obsoleto e requer alguma atualização, mas ainda é um bom ponto-de-referência para aprender a utilizar.

191 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 Uma característica importante do Mercurial é o seu repositório, projetado para ter um armazenamento muito eficiente, seguro e rápido. As revisões são compostas de dois identificadores distintos: um número serial particular do repositório, que inicia na revisão zero (primeiro commit), e um hash SHA-1 do changeset global (igual para todos os repositórios do mesmo projeto). Como há menos liberdade de organização do conteúdo do repositório, é sugerido que se tenha um repositório para cada subprojeto, usando opcionalmente uma floresta (forest) para agrupar diversos subprojetos.

192 Trabalhando com Mercurial Ciclo de trabalho 1. Início do projeto (init) hg init ➊ hg init 83 O ciclo básico de trabalho com Mercurial começa ao dar a partida no projeto. A configuração inicial do projeto é muito mais simples do que com Subversion; o repositório é construído e inicializado automaticamente sob o diretório corrente, e o usuário já pode começar a trabalhar sobre o projeto sem maiores preocupações.

193 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 O usuário pode trabalhar e submeter ao seu repositório local da mesma forma como faria com Subversion. Submissões (commit) são sempre locais, ou seja, registradas em seu repositório local e particular apenas. Outros comandos são utilizados para compartilhar suas submissões com outros usuários.

194 Trabalhando com Mercurial Ciclo de trabalho 3. Ramificação hg clone ➌ hg clone 85 Quando um segundo desenvolvedor se junta ao projeto, este deve clonar o repositório já existente do primeiro desenvolvedor, criando assim sua ramificação particular do projeto.

195 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 Cada desenvolvedor continua a trabalhar sobre o seu repositório particular.

196 Trabalhando com Mercurial Ciclo de trabalho 5. Mescla hg pull, push ➎ hg pull hg push 87 Em determinado momento, os desenvolvedores decidem compartilhar suas submissões, de forma a unificar (mesclar) as alterações de cada um. Essas operações são chamadas de empurrar (push) e puxar (pull) submissões.

197 Trabalhando com Mercurial Ciclo de trabalho hg pull hg pull hg pull hg pull 88 Quando muitos desenvolvedores trabalham sobre o mesmo projeto, cada um deve puxar as alterações dos outros.

198 Trabalhando com Mercurial Ciclo de trabalho hg pull hg pull hg pull hg pull hg push 89 Uma abordagem centralizada pode ser utilizada quando necessária. Nesse cenário, quando um desenvolvedor deseja compartilhar alterações com outros desenvolvedores (equivalente ao commit do Subversion), este empurra suas submissões para um servidor dedicado, de onde os outros desenvolvedores podem puxar (equivalente ao update do Subversion).

199 Trabalhando com Mercurial Ciclo de trabalho hg import hg import hg import hg import hg export lista de s 90 Se um servidor dedicado não estiver disponível, uma lista de s onde todos os desenvolvedores participam pode ser utilizada. Nesse cenário, o desenvolvedor exporta suas submissões para a lista de s, e cada outro desenvolvedor importa as submissões para seus repositórios locais.

200 Trabalhando com Mercurial Ciclo de trabalho Mercurial Subversion (distribuído) (centralizado) 1 * Remoto push pull Local 1 update commit update commit 1 * 91 O ponto-de-vista distribuído, adotado pelo Mercurial, é centrado na cópia de trabalho local do usuário, no sentido de que o usuário enxerga a sua cópia de trabalho, com seu repositório local, lidando com diversos outros repositórios externos. O ponto-de-vista centralizado, adotado pelo Subversion, é centrado no repositório, no sentido de que o usuário enxerga o repositório como único, sendo a sua cópia de trabalho uma entre muitas que lidam diretamente com o repositório. Comparativamente, o Mercurial recupera alterações de outros desenvolvedores através de duas etapas (pull+update) que equivalem a uma etapa do Subversion (update); e envia alterações também através de duas etapas (commit+push) que equivalem a uma do Subversion (commit).

201 Trabalhando com Mercurial Grafo de revisões tip 3: 3a63 2: ecf3 0: 9117 Bob Alice 1: 273c 92 As revisões em um repositório Mercurial (igualmente para Git, Bazaar e outros VCSes distribuídos) são representadas por grafos acíclicos dirigidos (DAG: Directed Acyclic Graph). Isso significa que há uma relação de hierarquia entre revisões, e não há caminhos que levam de uma revisão à ela mesma. Cada revisão possui como ascendente a revisão sobre a qual alterações foram feitas e cuja submissão gerou tal revisão. Um caso especial é a revisão inicial, que não possui ascendentes. Mercurial chama de ponta (tip) a revisão mais recente do repositório.

202 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: A clonagem consiste em fazer uma cópia de todas as revisões do repositório de origem para um novo repositório. Nesta ilustração, Bob clona o repositório de Alice. Após a clonagem, ambos os repositórios são virtualmente idênticos, e independentes. A única diferença entre os repositórios é que o clone mantém uma referência ao seu repositório de origem, eliminando a necessidade de fornecer novamente seu endereço em futuros comandos de replicação.

203 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: Alice e Bob continuam trabalhando cada um em sua cópia do repositório do projeto, cada um em sua ramificação particular, divergindo do histórico em comum.

204 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 Em determinado momento Bob resolve trazer (puxar) as alterações de Alice para o seu repositório. Mas as submissões de Alice são descendentes da última revisão em comum entre os dois repositórios. Isso criará uma ramificação no repositório de Bob. Neste momento, haverá duas cabeças (heads) no repositório de Bob. Cabeças são revisões sem descendentes. Toda cabeça é uma ramificação implícita do projeto. A cópia de trabalho continua na revisão original antes de puxar as submissões de Alice. O comando update irá falhar, pois não há ainda um caminho direto da revisão corrente (5) para a ponta (7).

205 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 Bob mescla a cabeça recém obtida ao puxar as submissões de Alice em sua cópia de trabalho (originalmente ligada à revisão 5 nesta ilustração). A cópia de trabalho terá então duas revisões ascendentes, e conterá tanto as alterações da ramificação de Bob (3 4 5) quanto as de Alice (3 6 7). Note que as revisões obtidas de Alice possuem identificadores seriais diferentes no repositório de Bob, mas os mesmos identificadores SHA-1.

206 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 Bob então submete sua mescla para seu repositório local, criando uma nova revisão que converge as duas ramificações novamente em uma única cabeça, que também é a nova ponta do repositório.

207 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 hg pull (alice) hg push (bob) 3: 3a63 Bob Alice 3: 3a63 2: ecf3 98 Se Bob tiver permissão de escrita ao repositório de Alice, ele poderá empurrar suas novas submissões, incluindo sua mescla das duas ramificações. Caso contrário, Alice pode puxar as submissões de Bob para seu repositório, o efeito é idêntico. Note que a cópia de trabalho de Alice continuará na revisão original antes da sincronização. Alice precisa atualizar sua cópia de trabalho para a ponta do repositório (hg update) para ver as alterações trazidas do repositório de Bob.

208 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 O conjunto de comandos do Mercurial é muito semelhante ao do Subversion. Mesmo comandos cujo nomes padrões são diferentes possuem apelidos que os tornam compatíveis entre si (por exemplo, hg blame e svn annotate, hg delete e svn remove, hg move e svn rename). Essa compatibilidade é muito útil e ajuda no aprendizado paralelo de ambas as ferramentas. Os comandos variam nas opções que aceitam, mas sempre há o comando help para guiar durante a utilização.

209 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 Mercurial oferece três formas básicas de se acessar outros repositórios. Assim como o Subversion, cada forma de acesso é representada pelo esquema do endereço passado para os comandos. Para acesso a um repositório local, hospedado na mesma máquina, é utilizado o esquema file://, que pode ser omitido. Repositórios remotos podem ser acessados via HTTP ou via SSH se o usuário possuir um login shell no servidor remoto.

210 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 A cópia de trabalho começa sempre de uma entre duas formas diferentes: em branco, ou como uma cópia de outro repositório. O comando hg init é utilizado para criar um novo projeto, em branco. O comando transforma o diretório atual (ou qualquer outro diretório informado) em uma cópia de trabalho. O comando hg clone é utilizado para clonar um repositório já existente, criando uma nova cópia de trabalho que contém todo o histórico do repositório original. O comando hg clone é, de certa forma, análogo ao svn checkout, com a importante diferença de que todo o histórico do projeto é copiado. «Demonstração: inicialização e clonagem»

211 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 Para trazer submissões de outro repositório, o comando hg pull é utilizado. Por padrão, o seu repositório de origem é utilizado (aquele fornecido ao comando hg clone). É possível verificar quais submissões serão trazidas, sem realizar qualquer ação de fato, através do comando hg incomming. «Demonstração: puxar submissões»

212 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 Para levar submissões para outro repositório, o comando hg push é utilizado. Por padrão, o seu repositório de origem é utilizado (aquele fornecido ao comando hg clone). É possível verificar quais submissões serão levadas, sem realizar qualquer ação de fato, através do comando hg outgoing. «Demonstração: empurrar submissões»

213 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 Ao puxar submissões de outro repositório, pode ser necessário mesclar as alterações trazidas ao repositório local. O comando hg pull informa quando a mescla é necessária. O comando hg heads mostra quais são as cabeças do grafo de revisões, isso é, todas as ramificações que não possuem descendentes (e são fortes candidatas a serem mescladas). O comando hg merge é utilizado para mesclar uma ramificação à cópia de trabalho, para em seguida ser submetida como uma revisão que converge as duas ramificações. «Demonstração: mescla»

214 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 O comando hg status funciona como seu equivalente do Subversion. O comando hg identify mostra a revisão atual da cópia de trabalho, fornecendo uma funcionalidade semelhante ao comando svn info. O comando hg parents mostra as revisões ascendentes da revisão atual. Útil ao consultar revisões de mescla.

215 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 O comando hg log, assim como o Subversion, mostra uma descrição textual das alterações ocorridas ao longo do histórico do projeto armazenado no repositório. O comando hg view permite visualizar o histórico interativamente, incluindo o grafo de revisões, permitindo uma clara identificação das ramificações e mesclas. «Demonstração: visualização»

216 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 Há várias formas de se utilizar ramificações. Devido à natureza do controle de versões distribuído, a simples clonagem do repositório é uma forma prática de se criar uma nova ramificação. Mercurial utiliza um armazenamento eficiente que evita a duplicação do repositório para ramificações locais. Ramificações locais anônimas são criadas implicitamente quando submissões são criadas sobre revisões intermediárias, como já vimos ao puxar submissões de outros repositórios. É possível também criar ramificações explicitamente, com nomes, dentro do próprio repositório através do comando hg branch. «Demonstração: ramificações»

217 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 Rótulos são tratados de forma especial. Cada rótulo faz referência a um determinado changeset, ou revisão, do repositório. Rótulos fazem parte do controle de versões. Isso significa que o Mercurial registra quando um rótulo é criado ou removido, assim como o faz com arquivos comuns. Cada rótulo criado ou removido causa uma nova submissão ao repositório, que registra a alteração. «Demonstração: rótulos»

218 Obrigado! Juliano F. Ravasi Esta apresentação: A versão mais recente desta apresentação pode ser encontrada em: Copyright 2008 Juliano F. Ravasi Licensed under Creative Commons AttributionNoncommercial-Share Alike 2.5 Brazil License