Sistemas de Controle de Versão

Transcrição

Sistemas de
Controle de Versão
Juliano F. Ravasi
Setembro / 2008
http://juliano.info/
Conteúdo
●
●
●
Setembro/2008
Parte 1:
Controle de Versões
Parte 2:
Trabalhando com Subversion
Parte 3:
Trabalhando com Mercurial
Juliano F. Ravasi - Sistemas de Controle de Versão
2
Setembro/2008
3
Motivação
O que é controle de versões?
●
Gerenciamento de múltiplas revisões
–
–
–
–
–
Setembro/2008
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
Motivação
●
Vários nomes:
–
–
–
–
–
●
Setembro/2008
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
Motivação
Por que controle de versões?
●
Software é algo caro de ser produzido
–
–
–
Setembro/2008
Consome muito tempo
Exige cooperação, organização, disciplina
É importante armazenar tudo que é feito
6
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.
Setembro/2008
7
Motivação
Onde é utilizado?
Setembro/2008
8
Motivação
Onde é utilizado?
Setembro/2008
9
Recursos
Registro de revisões
●
Toda alteração realizada é registrada
–
–
–
●
Rápido acesso a revisões anteriores
–
–
Setembro/2008
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
Recursos
Auditoria
●
●
●
Setembro/2008
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
Recursos
Ramificações
●
●
Setembro/2008
Múltiplas linhas de desenvolvimento
dentro do mesmo projeto
Permite divergência e reconvergência do
desenvolvimento
12
Recursos
Trabalho cooperativo
●
●
Setembro/2008
Vários desenvolvedores trabalhando
sobre o mesmo projeto
Mescla das alterações dos diversos
desenvolvedores ou ramificações
13
Recursos
Segurança
●
●
●
Setembro/2008
Autenticação criptográfica de histórico
Controle de acesso sobre o repositório
Cópias de segurança (backup)
14
Modelos
●
Centralizado (cliente-servidor)
–
–
●
Distribuído
–
–
Setembro/2008
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
Modelos
●
Vantagens:
–
–
–
●
Desvantagens:
–
–
Setembro/2008
Controle de acesso
Cópia de segurança
Controle de qualidade
Dependência do repositório central
Ponto único de falha
16
Modelos
Distribuído
●
Vantagens:
–
–
–
●
Desvantagens:
–
–
Setembro/2008
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
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
–
Setembro/2008
Opiniões inflamadas, guerra de egos
Cada modelo de desenvolvimento exige um
modelo de controle de versões
18
Conceitos
Repositório
●
●
Núcleo do controle de versões
Possui uma “linha do tempo” embutida
–
Setembro/2008
Coletânea de revisões do projeto
19
Conceitos
Repositório
●
Revisão
–
–
Setembro/2008
Estado em um determinado instante
Imutável após criada
20
Conceitos
Cópia de trabalho
●
Cópia do repositório em certa revisão
–
–
Setembro/2008
Geralmente a mais recente
Checkout (obtenção de uma cópia)
21
Conceitos
Cópia de trabalho
●
Onde ocorre o desenvolvimento
–
–
O sistema reconhece as alterações feitas
Algumas operações devem ser explícitas
●
Setembro/2008
Adição, remoção, moção e cópia de arquivos
22
Conceitos
Cópia de trabalho
●
Submissão (commit)
–
Setembro/2008
Alterações são registradas em uma nova
revisão do repositório
23
Conceitos
Ramificações (branches)
●
Linhas alternativas de desenvolvimento
–
–
Setembro/2008
Explícitas
Implícitas
24
Conceitos
●
Explícitas
–
–
–
Setembro/2008
Manutenção de versões legadas
Implementação de novos recursos
Experiências no código do projeto
25
Conceitos
●
Implícitas
–
–
Setembro/2008
Cópia de trabalho
Múltiplos desenvolvedores
26
Conceitos
Mescla (merge)
●
Reintegração de ramificações
–
–
Em grande parte é automatizado
Conflitos podem ocorrer
●
Setembro/2008
O desenvolvedor pode precisar interagir
27
Conceitos
Rótulos (tags)
●
Setembro/2008
Nomes atribuídos a revisões
28
Fluxos de trabalho
●
●
Solitário
Centralizado
–
–
●
Distribuído
–
–
–
Setembro/2008
Repositório local
Repositório remoto
Parceiro
Equipe
Hierárquico
29
Fluxos de trabalho
●
Setembro/2008
Solitário
30
Fluxos de trabalho
●
Setembro/2008
Centralizado, repositório local
31
Fluxos de trabalho
●
Setembro/2008
Centralizado, repositório remoto
32
Fluxos de trabalho
●
Setembro/2008
Distribuído, parceiro
33
Fluxos de trabalho
●
Setembro/2008
Distribuído, equipe
34
Fluxos de trabalho
●
Setembro/2008
Distribuído, hierárquico
35
Sistemas de controle de versões
SourceAnyware
Vault
Git
darcs
MOG
ArX
Surround
FtpVC
PlasticSCM
CVS
Store
Stellation
ClearCase
Vesta
AllFusion
SourceSafe
DCVS
Aegis
Setembro/2008
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
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
Setembro/2008
PlasticSCM
37
●
Visão geral dos VCSs abertos:
–
Centralizados:
●
▶
–
▶
●
●
http://subversion.tigris.org/
Git
Mercurial
Bazaar
...
http://git.or.cz/
http://www.selenic.com/mercurial/
http://bazaar-vcs.org/
Mais:
–
–
Setembro/2008
http://www.nongnu.org/cvs/
Distribuídos:
●
●
CVS
Subversion
http://linuxmafia.com/faq/Apps/vcs.html
http://en.wikipedia.org/wiki/List_of_revision_control_software
38
Sistemas de controle de versão
CVS
●
●
●
●
●
●
Setembro/2008
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
Subversion
●
“Sucessor” do CVS
–
●
●
●
●
●
●
Setembro/2008
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
●
Projeto em camadas
–
Repositório
●
–
Acesso ao repositório
●
–
–
Bindings: C, Python, Perl, Java, Ruby
Cliente
●
Setembro/2008
Local, WebDAV, svnserve
Cópia de trabalho
Biblioteca de cliente
●
–
BorlandDB, fsfs
svn, TortoiseSVN, Subclipse, KDESvn, Trac, ...
41
Git
●
Criado para gerenciar o kernel do Linux
–
–
●
●
●
●
●
●
Setembro/2008
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
42
Mercurial
●
Criado simultaneamente ao Git
–
●
●
●
●
●
Setembro/2008
Desenvolvido por Matt Mackall
Modelo distribuído
Ênfase em uso por grandes projetos
Escrito em Python, modular
43
Bazaar
●
●
●
Desenvolvido por Canonical Inc.
Modelo distribuído
Ênfase em facilidade, flexibilidade
–
●
●
Setembro/2008
Suporte a múltiplos fluxos de trabalho
Desempenho ruim
44
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”
●
Setembro/2008
a menos que sejam criados por um processo automático
(por ex: ./configure)
45
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
Setembro/2008
46
Trabalhando com
Subversion
Setembro/2008
47
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:
–
–
–
Setembro/2008
Armazenados em lugares distintos
Propriedades
Diretórios
WebDAV
48
●
Recomendação
–
●
Usar versão 1.5 ou superior.
Informações
–
–
–
Projeto: http://subversion.tigris.org/
Manual: http://svnbook.red-bean.com/
Clientes:
●
●
●
Setembro/2008
Windows: http://tortoisesvn.tigris.org/
Eclipse: http://subclipse.tigris.org/
KDE: http://kdesvn.alwins-world.de/
49
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:
–
Setembro/2008
Cópias leves, copy-on-write
Banco-de-dados transacional
Um repositório por projeto
(incluindo subprojetos)
50
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/
Setembro/2008
← tronco
← ramificações
← rótulos
51
Repositório
●
Setembro/2008
52
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 "..."
Setembro/2008
53
Ciclo de trabalho
●
1. Obtenção (checkout)
–
svn checkout
❶ svn checkout
Setembro/2008
54
Ciclo de trabalho
●
2. Desenvolvimento
❷ (edição)
Setembro/2008
55
Ciclo de trabalho
●
3. Comparação, reversão
–
–
–
svn status
svn diff
svn revert
❸ svn diff
svn revert
Setembro/2008
56
Ciclo de trabalho
●
4. Submissão
–
svn commit
❹ svn commit
Setembro/2008
57
Ciclo de trabalho
●
5. Atualização
–
svn update
❺ svn update
Setembro/2008
58
Comandos
●
Ferramentas principais:
–
svn
●
–
svnadmin
●
●
Manutenção do repositório.
Outras ferramentas:
–
–
–
–
Setembro/2008
Cliente padrão, cópia de trabalho.
svndumpfilter
svnlook
svnserve
svnsync
59
Comandos
●
–
Local
●
–
WebDAV sobre HTTP
●
●
–
svn://svn.example.com/svn/repo/...
svnserve sobre SSH
●
Setembro/2008
http://svn.example.com/svn/repo/...
https://svn.example.com/svn/repo/...
svnserve
●
–
file:///home/user/svn/repo/...
svn+ssh://svn.example.com/svn/repo/...
60
Comandos
●
–
Composição da URL
svn://svn.example.com/svn/project/subproject/trunk/
Endereço do
servidor Subversion
Setembro/2008
Endereço do
repositório
Caminho armazenado
no repositório
61
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]
●
Setembro/2008
Importa um projeto existente em um repositório.
Atualiza a cópia de trabalho com o repositório.
62
Comandos
●
Edição
–
svn add alvo
●
–
svn delete alvo
●
–
Cria uma cópia de um arquivo ou diretório.
svn move orig dest
●
Setembro/2008
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
Comandos
●
Consulta e comparação
–
svn status [alvo]
●
–
svn diff [alvo]
●
●
Mostra alterações realizadas em arquivos.
Reversão
–
svn revert [alvo]
●
Setembro/2008
Mostra arquivos alterados, adicionados, etc.
Reverte alterações realizadas em arquivos.
64
Comandos
●
Submissão
–
svn update
●
●
–
svn commit [alvo]
●
●
Setembro/2008
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
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]
●
Setembro/2008
Resolução simples, informa qual versão do alvo
deverá ser preservada.
Após resolver os conflitos, tentar submeter
novamente.
66
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
●
Setembro/2008
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
Consulta de histórico (svn log)
r3 | juliano | 2008-07-18 00:41:18 -0300 (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.
Setembro/2008
68
Atualização (svn update)
●
Para visitar revisões passadas
–
–
●
Para retornar à última revisão
–
●
svn update
Legenda
–
–
–
–
–
–
Setembro/2008
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
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]
●
Setembro/2008
Alterações entre revisões ‘x’ e ‘y’.
Alterações entre revisões ‘x’-1 e ‘x’.
70
Setembro/2008
71
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
–
Setembro/2008
A:
C:
D:
I:
M:
R:
X:
?:
!:
svn help status
72
Ramificações
●
Comandos
–
svn copy repo/trunk
repo/branches/branch
●
–
–
svn switch repo/trunk
svn switch repo/branch/branch
●
Setembro/2008
Cria uma nova ramificação.
Alterna entre ramificações.
73
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
●
Setembro/2008
Mescla alterações de uma ramificação diferente
na ramificação atual da cópia de trabalho.
Mescla apenas revisão ‘rev’.
74
Mescla e reversão
●
Reversão
–
svn merge -c -rev URL
●
●
●
Setembro/2008
Desfaz as alterações da revisão ‘rev’.
Pode ser usado na própria ramificação.
É uma mescla “ao contrário”.
75
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
●
Setembro/2008
Cria um novo rótulo.
76
Propriedades
●
Comandos
–
svn proplist [alvo]
●
–
svn propget prop alvo
●
–
Altera uma propriedade (no editor externo).
svn propdel prop alvo
●
Setembro/2008
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
Propriedades
●
Propriedades padrão
–
Diretórios e arquivos
●
●
●
●
●
●
●
–
Revisões
●
●
●
Setembro/2008
svn:eol-style
svn:executable
svn:externals
svn:ignore
svn:keywords
svn:mime-type
svn:needs-lock
svn:author
svn:date
svn:log
78
Trabalhando com
Mercurial
Setembro/2008
79
●
Distribuído
–
●
–
–
Setembro/2008
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
●
Informações
–
–
–
Projeto: http://www.selenic.com/mercurial/
Manual: http://hgbook.red-bean.com/
Clientes:
●
●
Setembro/2008
Windows: http://tortoisehg.sourceforge.net/
Eclipse:
http://www.vectrace.com/mercurialeclipse/
81
Repositório
●
Sistema de arquivos
–
–
Armazenamento eficiente, seguro e rápido
Revisões:
●
●
●
–
–
Setembro/2008
Numéricas, seriais
Hash SHA-1 do changeset
Um repositório por subprojeto
Projeto: vários subprojetos agrupados
82
Ciclo de trabalho
●
1. Início do projeto (init)
–
hg init
➊ hg init
Setembro/2008
83
Ciclo de trabalho
●
2. Desenvolvimento, submissão local
–
hg status, diff, revert, commit
➋ hg
hg
hg
hg
Setembro/2008
status
diff
revert
commit
84
Ciclo de trabalho
●
3. Ramificação
–
hg clone
➌ hg clone
Setembro/2008
85
Ciclo de trabalho
●
4. Mais desenvolvimento
➍ hg
hg
hg
hg
Setembro/2008
status
diff
revert
commit
➍ hg
hg
hg
hg
status
diff
revert
commit
86
Ciclo de trabalho
●
5. Mescla
–
hg pull, push
➎ hg pull
hg push
Setembro/2008
87
Ciclo de trabalho
Setembro/2008
hg pull
hg pull
hg pull
hg pull
88
Ciclo de trabalho
hg pull
hg pull
hg pull
hg pull
hg push
Setembro/2008
89
Ciclo de trabalho
hg import
hg import
hg import
hg import
hg export
lista de e-mails
Setembro/2008
90
Ciclo de trabalho
Mercurial
Subversion
(distribuído)
(centralizado)
1
*
Remoto
push
pull
Local
1
update
commit
update
commit
1
Setembro/2008
*
91
Grafo de revisões
tip
3: 3a63
2: ecf3
Setembro/2008
0: 9117
Bob
Alice
1: 273c
92
Grafo de revisões
tip
tip
3: 3a63
3: 3a63
2: ecf3
2: ecf3
Setembro/2008
0: 9117
1: 273c
hg clone
Bob
Alice
1: 273c
0: 9117
93
Setembro/2008
tip
tip
5: 5f24
5: 5102
4: ce3b
4: 207f
3: 3a63
3: 3a63
2: ecf3
2: ecf3
1: 273c
1: 273c
0: 9117
Bob
Alice
Grafo de revisões
0: 9117
94
Grafo de revisões
tip
7: 5f24
6: ce3b
tip
5: 5f24
5: 5102
4: ce3b
4: 207f
Setembro/2008
2: ecf3
3: 3a63
hg pull
Bob
Alice
3: 3a63
2: ecf3
95
Grafo de revisões
merge
hg merge
tip
7: 5f24
tip
6: ce3b
5: 5f24
5: 5102
4: ce3b
4: 207f
Setembro/2008
2: ecf3
3: 3a63
Bob
Alice
3: 3a63
2: ecf3
96
Grafo de revisões
tip
8: b4d0
7: 5f24
tip
6: ce3b
5: 5f24
5: 5102
4: ce3b
4: 207f
Setembro/2008
2: ecf3
3: 3a63
Bob
Alice
3: 3a63
2: ecf3
97
Grafo de revisões
tip
tip
8: b4d0
8: b4d0
7: 5102
7: 5f24
6: 207f
6: ce3b
5: 5f24
5: 5102
4: ce3b
4: 207f
Setembro/2008
2: ecf3
3: 3a63
Bob
Alice
3: 3a63
hg pull (alice)
hg push (bob)
2: ecf3
98
Comandos
●
Comandos comuns
–
–
–
–
–
–
–
–
–
–
–
–
Setembro/2008
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
Comandos
●
Acesso a repositórios
–
Local
●
●
–
HTTP, Mercurial
●
●
–
http://hg.example.com/hg/project/
https://hg.example.com/hg/project/
SSH, Mercurial
●
Setembro/2008
/home/user/hg/project/
file:///home/user/hg/project/
ssh://hg.example.com/hg/project/
100
Criação e clonagem
●
Criação do projeto
–
hg init [diretório]
●
●
Clonagem
–
hg clone origem [diretório]
●
●
●
Setembro/2008
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
Trabalho distribuído
●
Trazer (puxar) submissões
–
hg pull [URL]
●
●
●
–
hg incoming [URL]
●
Setembro/2008
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
●
Levar (empurrar) submissões
–
hg push [URL]
●
●
●
–
hg outgoing [URL]
●
Setembro/2008
Determina as diferenças entre o seu repositório
e o indicado, e as aplica remotamente.
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
●
Mescla
–
hg heads [rev]
●
–
hg merge [rev]
●
●
Setembro/2008
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
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]
●
Setembro/2008
Mostra as revisões ascendentes da revisão atual
(ou a revisão fornecida).
105
Consulta ao histórico
●
Histórico
–
hg log [-v]
●
●
Visualização
–
hg view
●
●
Setembro/2008
Descrição textual do histórico.
Visualiza o histórico interativamente.
Grafo de revisões.
106
Ramificações
●
Clonagem
–
–
–
●
Locais, anônimas
–
–
●
Criadas implicitamente
Submissão sobre revisão intermediária
Locais, explícitas
–
–
Setembro/2008
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
Rótulos
●
●
●
Referenciam determinados changesets
Fazem parte do controle de versões
Comandos
–
hg tag [-l] [-r rev] nome
●
●
–
hg tag [-l] --remove nome
●
Setembro/2008
Cria um novo rótulo ‘nome’ para a revisão ‘rev’.
Parâmetro ‘-l’: rótulo local.
Apaga um rótulo.
108
Obrigado!
Juliano F. Ravasi
Esta apresentação:
http://juliano.info/pt/vcs
Setembro/2008
109
Sistemas de
Controle de Versão
Juliano F. Ravasi
Setembro / 2008
Setembro/2008
1
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 2008.1.
Copyright © 2008 – Juliano F. Ravasi
Licensed under Creative Commons AttributionNoncommercial-Share Alike 2.5 Brazil License
Conteúdo
●
●
●
Setembro/2008
Parte 1:
Parte 2:
Parte 3:
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.
Setembro/2008
Parte 1: Controle de Versões
●
●
●
●
Motivação
Recursos
Conceitos
● Fluxos de trabalho
● Sistemas de controle de versões
● O que armazenar?
● O que não armazenar?
3
Motivação
●
Gerenciamento de múltiplas revisões
–
–
–
–
–
Setembro/2008
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.
Motivação
●
Vários nomes:
–
–
–
–
–
●
Setembro/2008
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.
Motivação
Por que controle de versões?
●
Software é algo caro de ser produzido
–
–
–
Setembro/2008
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.
Motivação
Onde é utilizado?
●
●
●
●
Sistemas de arquivos
Suítes de escritório
Ambientes colaborativos
Importante para qualquer desenvolvedor ou
empresa de desenvolvimento de software.
Setembro/2008
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.
Motivação
Onde é utilizado?
Setembro/2008
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.
Motivação
Onde é utilizado?
Setembro/2008
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.
Recursos
Registro de revisões
●
Toda alteração realizada é registrada
–
–
–
●
Rápido acesso a revisões anteriores
–
–
Setembro/2008
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.
Recursos
Auditoria
●
●
●
Setembro/2008
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.
Recursos
Ramificações
●
●
Setembro/2008
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.
Recursos
Trabalho cooperativo
●
●
Setembro/2008
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.
Recursos
Segurança
●
●
●
Setembro/2008
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.
Modelos
●
–
–
●
Distribuído
–
–
Setembro/2008
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 1970. 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.
Modelos
●
Vantagens:
–
–
–
●
Desvantagens:
–
–
Setembro/2008
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.
Modelos
Distribuído
●
Vantagens:
–
–
–
●
Desvantagens:
–
–
Setembro/2008
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.
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
–
Setembro/2008
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.
Conceitos
Repositório
●
●
Núcleo do controle de versões
Possui uma “linha do tempo” embutida
–
Setembro/2008
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.
Conceitos
Repositório
●
Revisão
–
–
Setembro/2008
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.
Conceitos
Cópia de trabalho
●
Cópia do repositório em certa revisão
–
–
Setembro/2008
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.
Conceitos
Cópia de trabalho
●
Onde ocorre o desenvolvimento
–
–
O sistema reconhece as alterações feitas
Algumas operações devem ser explícitas
●
Setembro/2008
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.
Conceitos
Cópia de trabalho
●
Submissão (commit)
–
Setembro/2008
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.
Conceitos
●
Linhas alternativas de desenvolvimento
–
–
Setembro/2008
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.
Conceitos
●
Explícitas
–
–
–
Setembro/2008
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.
Conceitos
●
Implícitas
–
–
Setembro/2008
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.
Conceitos
Mescla (merge)
●
Reintegração de ramificações
–
–
Em grande parte é automatizado
Conflitos podem ocorrer
●
Setembro/2008
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.
Conceitos
Rótulos (tags)
●
Setembro/2008
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.
Fluxos de trabalho
●
●
Solitário
Centralizado
–
–
●
Distribuído
–
–
–
Setembro/2008
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.
Fluxos de trabalho
●
Setembro/2008
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.
Fluxos de trabalho
●
Setembro/2008
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.
Fluxos de trabalho
●
Setembro/2008
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.
Fluxos de trabalho
●
Setembro/2008
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.
Fluxos de trabalho
●
Setembro/2008
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.
Fluxos de trabalho
●
Setembro/2008
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.
SourceAnyware
Vault
Git
darcs
MOG
ArX
Surround
FtpVC
PlasticSCM
CVS
Store
Stellation
ClearCase
Vesta
AllFusion
codeBeamer
Perforce
SourceSafe
DCVS
GNU arch
CodeVille
Aegis
Setembro/2008
PureCM
Mercurial
RCS
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.
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
Setembro/2008
PlasticSCM
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.
●
Visão geral dos VCSs abertos:
–
Centralizados:
●
▶
–
▶
●
●
http://subversion.tigris.org/
Git
Mercurial
Bazaar
...
http://git.or.cz/
http://www.selenic.com/mercurial/
http://bazaar-vcs.org/
Mais:
–
–
Setembro/2008
http://www.nongnu.org/cvs/
Distribuídos:
●
●
CVS
Subversion
http://linuxmafia.com/faq/Apps/vcs.html
http://en.wikipedia.org/wiki/List_of_revision_control_software
38
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.
CVS
●
●
●
●
●
●
Setembro/2008
Criado para substituir o RCS (1980s)
Obsoleto, desenvolvimento estagnado
Modelo centralizado
Possui grande base de usuários
Possui defeitos e limitações de projeto
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 1980.
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.
Subversion
●
“Sucessor” do CVS
–
●
●
●
●
●
●
Setembro/2008
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.
Subversion
●
Projeto em camadas
–
Repositório
●
–
●
–
–
Bindings: C, Python, Perl, Java, Ruby
Cliente
●
Setembro/2008
Local, WebDAV, svnserve
Cópia de trabalho
Biblioteca de cliente
●
–
BorlandDB, fsfs
svn, TortoiseSVN, Subclipse, KDESvn, Trac, ...
41
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.
Git
●
Criado para gerenciar o kernel do Linux
–
–
●
●
●
●
●
●
Setembro/2008
Após controvérsia sobre o BitKeeper
Inicialmente por Linus Torvalds
Modelo distribuído
Ênfase em desenvolvimento não-linear
Gerencia conteúdo, ao invés de arquivos
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.
Mercurial
●
Criado simultaneamente ao Git
–
●
●
●
●
●
Setembro/2008
Desenvolvido por Matt Mackall
Modelo distribuído
Ênfase em uso por grandes projetos
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.
Bazaar
●
●
●
Desenvolvido por Canonical Inc.
Modelo distribuído
Ênfase em facilidade, flexibilidade
–
●
●
Setembro/2008
Suporte a múltiplos fluxos de trabalho
Desempenho ruim
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.
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”
●
Setembro/2008
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”.
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
Setembro/2008
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.
Trabalhando com
Subversion
Setembro/2008
Parte 2: Trabalhando com Subversion
●
●
●
●
●
●
●
●
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
●
Repositório vs. cópia de trabalho
–
●
–
–
●
Implícito, parte da árvore do repositório
Criados através de cópias leves
Características únicas:
–
–
–
Setembro/2008
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.
●
Recomendação
–
●
Usar versão 1.5 ou superior.
Informações
–
–
–
Projeto: http://subversion.tigris.org/
Manual: http://svnbook.red-bean.com/
Clientes:
●
●
●
Setembro/2008
Windows: http://tortoisesvn.tigris.org/
Eclipse: http://subclipse.tigris.org/
KDE: http://kdesvn.alwins-world.de/
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.
Repositório
●
Sistema de arquivos
–
Baseado em ligações
●
●
–
Revisões numéricas, seriais
●
●
Revisão zero: repositório em branco
–
Setembro/2008
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.
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’.
/
trunk/
branches/
tags/
Setembro/2008
← 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.
Repositório
●
Setembro/2008
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.
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 "..."
Setembro/2008
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»
Ciclo de trabalho
●
1. Obtenção (checkout)
–
svn checkout
❶ svn checkout
Setembro/2008
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.
Ciclo de trabalho
●
2. Desenvolvimento
❷ (edição)
Setembro/2008
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.
Ciclo de trabalho
●
3. Comparação, reversão
–
–
–
svn status
svn diff
svn revert
❸ svn diff
svn revert
Setembro/2008
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.
Ciclo de trabalho
●
4. Submissão
–
svn commit
❹ svn commit
Setembro/2008
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.
Ciclo de trabalho
●
5. Atualização
–
svn update
❺ svn update
Setembro/2008
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.
Comandos
●
Ferramentas principais:
–
svn
●
–
svnadmin
●
●
Manutenção do repositório.
Outras ferramentas:
–
–
–
–
Setembro/2008
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.
Comandos
●
–
Local
●
–
WebDAV sobre HTTP
●
●
–
svn://svn.example.com/svn/repo/...
svnserve sobre SSH
●
Setembro/2008
http://svn.example.com/svn/repo/...
https://svn.example.com/svn/repo/...
svnserve
●
–
file:///home/user/svn/repo/...
svn+ssh://svn.example.com/svn/repo/...
60
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.
Comandos
●
–
Composição da URL
svn://svn.example.com/svn/project/subproject/trunk/
Endereço do
servidor Subversion
Setembro/2008
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.
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]
●
Setembro/2008
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»
Comandos
●
Edição
–
svn add alvo
●
–
svn delete alvo
●
–
Cria uma cópia de um arquivo ou diretório.
svn move orig dest
●
Setembro/2008
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»
Comandos
●
Consulta e comparação
–
svn status [alvo]
●
–
svn diff [alvo]
●
●
Mostra alterações realizadas em arquivos.
Reversão
–
svn revert [alvo]
●
Setembro/2008
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»
Comandos
●
Submissão
–
svn update
●
●
–
svn commit [alvo]
●
●
Setembro/2008
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»
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]
●
Setembro/2008
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»
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
●
Setembro/2008
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»
Consulta de histórico (svn log)
r3 | juliano | 2008-07-18 00:41:18 -0300 (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.
Setembro/2008
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.
Atualização (svn update)
●
Para visitar revisões passadas
–
–
●
Para retornar à última revisão
–
●
svn update
Legenda
–
–
–
–
–
–
Setembro/2008
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»
●
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]
●
Setembro/2008
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»
Setembro/2008
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).
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
–
Setembro/2008
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.
Ramificações
●
Comandos
–
svn copy repo/trunk
repo/branches/branch
●
–
–
svn switch repo/trunk
svn switch repo/branch/branch
●
Setembro/2008
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»
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
●
Setembro/2008
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»
Mescla e reversão
●
Reversão
–
svn merge -c -rev URL
●
●
●
Setembro/2008
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.
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
●
Setembro/2008
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»
Propriedades
●
Comandos
–
svn proplist [alvo]
●
–
svn propget prop alvo
●
–
Altera uma propriedade (no editor externo).
svn propdel prop alvo
●
Setembro/2008
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.
Propriedades
●
Propriedades padrão
–
Diretórios e arquivos
●
●
●
●
●
●
●
–
Revisões
●
●
●
Setembro/2008
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).
Trabalhando com
Mercurial
Setembro/2008
Parte 3: Trabalhando com Mercurial
●
●
●
●
●
●
●
●
Repositório
Ciclo de trabalho
Grafo de revisões
Comandos
● Criação e clonagem
Ramificações
Rótulos
79
●
Distribuído
–
●
–
–
Setembro/2008
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.
●
Informações
–
–
–
Projeto: http://www.selenic.com/mercurial/
Manual: http://hgbook.red-bean.com/
Clientes:
●
●
Setembro/2008
Windows: http://tortoisehg.sourceforge.net/
Eclipse:
http://www.vectrace.com/mercurialeclipse/
81
A versão atual (em Set/2008) do Mercurial é 1.0.2. 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.
Repositório
●
Sistema de arquivos
–
–
Armazenamento eficiente, seguro e rápido
Revisões:
●
●
●
–
–
Setembro/2008
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.
Ciclo de trabalho
●
1. Início do projeto (init)
–
hg init
➊ hg init
Setembro/2008
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.
Ciclo de trabalho
●
2. Desenvolvimento, submissão local
–
hg status, diff, revert, commit
➋ hg
hg
hg
hg
Setembro/2008
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.
Ciclo de trabalho
●
3. Ramificação
–
hg clone
➌ hg clone
Setembro/2008
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.
Ciclo de trabalho
●
4. Mais desenvolvimento
➍ hg
hg
hg
hg
Setembro/2008
status
diff
revert
commit
➍ hg
hg
hg
hg
status
diff
revert
commit
86
Cada desenvolvedor continua a trabalhar sobre o
seu repositório particular.
Ciclo de trabalho
●
5. Mescla
–
hg pull, push
➎ hg pull
hg push
Setembro/2008
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.
Ciclo de trabalho
Setembro/2008
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.
Ciclo de trabalho
hg pull
hg pull
hg pull
hg pull
hg push
Setembro/2008
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).
Ciclo de trabalho
hg import
hg import
hg import
hg import
hg export
lista de e-mails
Setembro/2008
90
Se um servidor dedicado não estiver disponível, uma
lista de e-mails onde todos os desenvolvedores
participam pode ser utilizada.
Nesse cenário, o desenvolvedor exporta suas
submissões para a lista de e-mails, e cada outro
desenvolvedor importa as submissões para seus
repositórios locais.
Ciclo de trabalho
Mercurial
Subversion
(distribuído)
(centralizado)
1
*
Remoto
push
pull
Local
1
update
commit
update
commit
1
Setembro/2008
*
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).
Grafo de revisões
tip
3: 3a63
2: ecf3
Setembro/2008
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.
Grafo de revisões
tip
tip
3: 3a63
3: 3a63
2: ecf3
2: ecf3
Setembro/2008
0: 9117
1: 273c
hg clone
Bob
Alice
1: 273c
0: 9117
93
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.
Setembro/2008
tip
tip
5: 5f24
5: 5102
4: ce3b
4: 207f
3: 3a63
3: 3a63
2: ecf3
2: ecf3
1: 273c
1: 273c
0: 9117
Bob
Alice
Grafo de revisões
0: 9117
94
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.
Grafo de revisões
tip
7: 5f24
6: ce3b
tip
5: 5f24
5: 5102
4: ce3b
4: 207f
Setembro/2008
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).
Grafo de revisões
merge
hg merge
tip
7: 5f24
tip
6: ce3b
5: 5f24
5: 5102
4: ce3b
4: 207f
Setembro/2008
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.
Grafo de revisões
tip
8: b4d0
7: 5f24
tip
6: ce3b
5: 5f24
5: 5102
4: ce3b
4: 207f
Setembro/2008
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.
Grafo de revisões
tip
tip
8: b4d0
8: b4d0
7: 5102
7: 5f24
6: 207f
6: ce3b
5: 5f24
5: 5102
4: ce3b
4: 207f
Setembro/2008
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.
Comandos
●
Comandos comuns
–
–
–
–
–
–
–
–
–
–
–
–
Setembro/2008
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.
Comandos
●
Acesso a repositórios
–
Local
●
●
–
HTTP, Mercurial
●
●
–
http://hg.example.com/hg/project/
https://hg.example.com/hg/project/
SSH, Mercurial
●
Setembro/2008
/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.
Criação e clonagem
●
Criação do projeto
–
hg init [diretório]
●
●
Clonagem
–
hg clone origem [diretório]
●
●
●
Setembro/2008
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»
●
Trazer (puxar) submissões
–
hg pull [URL]
●
●
●
–
hg incoming [URL]
●
Setembro/2008
Recupera as diferenças entre o repositório
indicado e o seu, e aplica as alterações.
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»
●
Levar (empurrar) submissões
–
hg push [URL]
●
●
●
–
hg outgoing [URL]
●
Setembro/2008
Determina as diferenças entre o seu repositório
e o indicado, e as aplica remotamente.
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»
●
Mescla
–
hg heads [rev]
●
–
hg merge [rev]
●
●
Setembro/2008
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»
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]
●
Setembro/2008
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.
Consulta ao histórico
●
Histórico
–
hg log [-v]
●
●
Visualização
–
hg view
●
●
Setembro/2008
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»
Ramificações
●
Clonagem
–
–
–
●
Locais, anônimas
–
–
●
Submissão sobre revisão intermediária
Locais, explícitas
–
–
Setembro/2008
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»
Rótulos
●
●
●
Referenciam determinados changesets
Fazem parte do controle de versões
Comandos
–
hg tag [-l] [-r rev] nome
●
●
–
hg tag [-l] --remove nome
●
Setembro/2008
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»
Obrigado!
Juliano F. Ravasi
Esta apresentação:
http://juliano.info/pt/vcs
Setembro/2008
109
A versão mais recente desta apresentação pode ser
encontrada em: http://juliano.info/pt/vcs
Copyright © 2008 – Juliano F. Ravasi
Licensed under Creative Commons AttributionNoncommercial-Share Alike 2.5 Brazil License

Sistemas de Controle de Versão

Transcrição

Documentos relacionados

ORDEM DO DIA 6028ª SESSÃO ORDINÁRIA da Câmara Municipal

svn - renesp.com.br

Rafaelle Magella de Santiago - PMI-CE

sorteio – touros – rodeio internacional quinta 28

Acesso - Grupo Escoteiro João de Barro 172/RS

hotspot

Sobreviventes e heróis de Santa Maria

- Você Faz o Design, Nós Executamos!

EMBAIXADA DA ITÁLIA EM LUANDA

Diretoria de Registro de Veículos REQUERIMENTO - Detran

0.193058001339498573_termo_de_convocacao_01_12 pdf