Introdução à Gerência de Configuraçãoleomurta/courses/2010.1/es2/aula5.pdf · 1. Apresentar,...
Transcript of Introdução à Gerência de Configuraçãoleomurta/courses/2010.1/es2/aula5.pdf · 1. Apresentar,...
Introdução
• A Engenharia de Software...
– Abordagem disciplinada para o desenvolvimento de software
– Grande diversidade de metodologias
Leonardo Murta Introdução à Gerência de Configuração 2
Introdução
• Ponto em comum nas metodologias:
– refinamentos sucessivos de artefatos
Leonardo Murta Introdução à Gerência de Configuração 3
http://www.colegiosaofrancisco.com.br
Mas aonde ficam esses artefatos?
Leonardo Murta Introdução à Gerência de Configuração 4
Tarefas de Engenharia de
Software
Artefato novo
Repositório
Artefato modificado
Artefato
O que são repositórios?
• Repositórios– Lugar seguro onde artefatos
são depositados
– Permitem armazenamento, busca e recuperação de artefatos
– Servem como um ponto de referência
– Apóiam no aumento da memória organizacional
Leonardo Murta Introdução à Gerência de Configuração 5
Gerência de Configuração
Desenvolvimento Liberação Implantação Produção
Leonardo Murta Introdução à Gerência de Configuração 6
Gerência de Configuração
Gerência de configuração de software é uma disciplina para o controle da evolução de sistemas de software (Susan Dart, 1991)
Leonardo Murta Introdução à Gerência de Configuração 7
Histórico
• Anos 50
– GC para produção de aviões de guerra e naves espaciais
• Anos 60 e 70
– Surgimento de GCS (S = Software)
– Foco ainda em aplicações militares e aeroespaciais
• Anos 80 e 90
– Mudança de foco (MIL EIA, IEEE, ISO, etc.)
– Surgimento das primeiras normas internacionais
– Assimilação por organizações não militares
Sistema de Gerência de Configuração
Leonardo Murta Introdução à Gerência de Configuração 8
Versão 1
Versão 2
Versão 3
Versão 4
Versão 5
Sistema de Gerência de Configuração
Leonardo Murta Introdução à Gerência de Configuração 9
Versão 1
Versão 2
Versão 3
Versão 4
Versão 5
Sistema de Gerência de Configuração
Leonardo Murta Introdução à Gerência de Configuração 10
Versão 1
Versão 2
Versão 3
Versão 4
Versão 5
Sistema de Gerência de Configuração
Leonardo Murta Introdução à Gerência de Configuração 11
Artefatos
Controle de Versões
Construção e Release
Controle de Modificações
Solicitações
Leonardo Murta Introdução à Gerência de Configuração 12
Sistema x Funções de GC
Ambiente de Desenvolvimento de Software
Identificação Controle Contabilização Avaliação Liberação
Controle de Modificações
Controle de Versões
Gerenciamento de Construção
Sistemas:
Processos:
Espaço de
trabalho:
Perspectiva de
integração
Perspectiva
gerencial
Perspectiva de
desenvolvimento
Este curso será guiado pelos sistemas de controle de
modificações e versões!
Exercício
1. Apresentar, na próxima aula, as 5 funções de gerência de configuração, citando exemplos
2. Apresentar, na próxima aula, o sistema de gerenciamento de construção e release, dando algum exemplo usando uma ferramenta (make, ant, maven, etc.)
3. Apresentar, na próxima aula, o que é integração contínua, dando algum exemplo usando uma ferramenta (Cruise Control, Apache Continuum, Hudson, etc.)
Leonardo Murta Introdução à Gerência de Configuração 13
Sistema de Gerência de Configuração
Leonardo Murta Introdução à Gerência de Configuração 14
Artefatos
Controle de Versões
Construção e Release
Controle de Modificações
Solicitações
Controle de versões
Leonardo Murta Introdução à Gerência de Configuração 15
Armazenamento?
Colaboração?
Consulta?
Topologia?
Topologia
Leonardo Murta Introdução à Gerência de Configuração 16
Repositório
Espaço deTrabalho
Centralizado Distribuído
ch
eck-i
n/
co
mm
it
ch
eck-o
ut/ u
pd
ate Repositório
Espaço deTrabalhoc
he
ck-i
n
ch
eck-o
ut/ u
pd
ate
Repositório
Espaço deTrabalho
clo
ne
/ pu
ll
pu
sh
Armazenamento
Leonardo Murta Introdução à Gerência de Configuração 17
v.3
v.2
v.1
Completo
delta 12
v.1
Forward
delta 23
delta 32
v.3
Reverse
delta 21
In-line
v.1 v.2/3
v.1/2 v.3
Colaboração
Leonardo Murta Introdução à Gerência de Configuração 18
m.3
m.2
m.1
Pessimista
junção
m.1
Otimista Misto
m.2 m.3
junção
m.1 m.2 m.3
Consulta
Leonardo Murta Introdução à Gerência de Configuração 19
Repositório (versão 1)
Artefato1 (versão 1)Artefato2 (versão 1)Artefato3 (versão 1)
Repositório (versão 2)
Artefato1 (versão 2)Artefato2 (versão 1)Artefato3 (versão 1)
Repositório (versão 0)
Repositório (versão 3)
Artefato1 (versão 2)Artefato2 (versão 3)Artefato3 (versão 1)Artefato4 (versão 3)
Repositório (versão 4)
Artefato1 (versão 4)Artefato2 (versão 3)Artefato3 (versão 4)Artefato4 (versão 3)
Artefato1Versão 1Versão 2Versão 4
Artefato2Versão 1Versão 3
Artefato3Versão 1Versão 4
Artefato4Versão 3
Consulta por artefato
1ª modificação
2ª modificação
4ª modificação3ª modificação
Consulta
Leonardo Murta Introdução à Gerência de Configuração 20
Repositório (versão 1)
Artefato1 (versão 1)Artefato2 (versão 1)Artefato3 (versão 1)
Repositório (versão 2)
Artefato1 (versão 2)Artefato2 (versão 1)Artefato3 (versão 1)
Repositório (versão 0)
1ª modificação
2ª modificação
Repositório (versão 3)
Artefato1 (versão 2)Artefato2 (versão 3)Artefato3 (versão 1)Artefato4 (versão 3)
Repositório (versão 4)
Artefato1 (versão 4)Artefato2 (versão 3)Artefato3 (versão 4)Artefato4 (versão 3)
4ª modificação3ª modificação
1ª modificaçãoArtefato1 adicionadoArtefato2 adicionadoArtefato3 adicionado
2ª modificaçãoArtefato1 modificado
3ª modificaçãoArtefato2 modificadoArtefato4 adicionado
Consulta por modificação
4ª modificaçãoArtefato1 modificadoArtefato3 modificado
Ramos (branches)
• Versões que não seguem a linha principal de desenvolvimento
• Fornecem isolamento para o processo de desenvolvimento – Ramos usualmente são migrados à linha principal de
desenvolvimento– A migração pode ser complicada no caso de isolamento longo
• Características dos ramos se comparados a espaços de trabalho– compartilhados por outras pessoas (espaços de trabalho são
isolados)– residem no servidor (espaços de trabalho residem no cliente)– históricos (espaços de trabalho são momentâneos)– permanentes (espaços de trabalho temporários)
Leonardo Murta Introdução à Gerência de Configuração 21
Leonardo Murta Introdução à Gerência de Configuração 22
Estratégia básica de Ramificação• Manutenção em série
– Ramo principal: evolução
– Ramos auxiliares: correções
• Foco
– Desenvolvimento in-house
– Cliente único (e.g.: aplicações Web)
• Dificuldade de manutenção de várias liberações em paralelo
Sistema
Rel. 1
1.0 1.1 1.2
Rel. 2
2.0 2.1
Verif. Verif.
RC1 RC2Evolução EvoluçãoDesenv.
Correção Correção Correção
Junção
• Processo de migração de
– Espaços de trabalho
– Ramos
Leonardo Murta Introdução à Gerência de Configuração 23
Linha 1Linha 2Linha 3
Linha 1’Linha 2
<Linha 1> ou <Linha 1’>?Linha 2<Linha 3> ou nada?
Linha 1Linha 2Linha 3
Linha 1’Linha 2
Linha 1’Linha 2Linha 3
Linha 1Linha 2
2-way merge 3-way merge
Introdução à Gerência de Configuração 24
Exemplo(junção no Eclipse)
Leonardo Murta
Exemplo de ferramentas de controle de versões
• Livre– Bazaar– Git– Mercurial– Subversion
• Comercial– BitKeeper (BitMover)– ClearCase (IBM Rational)– Perforce– PVCS (Serena)– StarTeam (Borland)– Synergy/CM (Telelogic)– Team Foundation Server (Microsoft)
Leonardo Murta Introdução à Gerência de Configuração 25
Sistema de Gerência de Configuração
Leonardo Murta Introdução à Gerência de Configuração 26
Artefatos
Controle de Versões
Construção e Release
Controle de Modificações
Solicitações
Baseline
• Configuração revisada e aprovada que serve como base para uma próxima etapa de desenvolvimento e que somente pode ser modificada via processo formal de GCS
• São estabelecidas ao final de cada fase de desenvolvimento– Análise (functional)– Projeto (allocated)– Implementação (product)
• Momento de criar: balanceamento entre controle e burocracia
Leonardo Murta Introdução à Gerência de Configuração 27
Baseline (níveis de controle)
Leonardo Murta Introdução à Gerência de Configuração 28
Coordenação c/ auditoria
Controle
Informal:•Pré baseline•Sem requisição•Sem aprovação•Sem verificação•Ágil•Ad-hoc
Formal:•Pós baseline•Com requisição•Com aprovação•Com verificação•Burocrático•Planejado
Nível de controle
Baseline (níveis de controle)
Req. Análise Projeto Análise Projeto Análise Projeto
1 Inform. - Formal Inform. Formal Formal
2 - - Inform. - Formal Inform.
Leonardo Murta Introdução à Gerência de Configuração 29
Requisito 1 Análise ProjetoBaseline 1:
•An. Req. 1
Requisito 2 Análise Projeto
Tempo
Baseline 2:•An. Req. 1•Pr. Req. 1•An. Req. 2
Controle de modificações
• Tarefas
– Solicitação de modificação
– Classificação da modificação
– Análise da modificação
– Avaliação da modificação
– Implementação da modificação
– Verificação da modificação
– Geração de baseline
Leonardo Murta Introdução à Gerência de Configuração 30
Leonardo Murta Introdução à Gerência de Configuração 31
Controle de modificações
[Leon, 2000] Requisição de modificação
Leonardo Murta Introdução à Gerência de Configuração 32
Controle de modificações
[White, 2000] Janela de criação de formulários do ClearQuest
Leonardo Murta Introdução à Gerência de Configuração 33
Controle de modificações
• O critério de classificação da modificação deve estar explicitado no plano de GC
• A classificação visa priorizar modificações mais importantes (críticas, fatais, não
fatais, cosméticas)
• A análise visa relatar os impactos em custo, cronograma, funcionalidades, etc.
da implementação da modificação
• Caso a análise conclua que não existe chance de aprovar a modificação (casos
extremos), pode ocorrer rejeição antes da avaliação para poupar custos no
processo
Leonardo Murta Introdução à Gerência de Configuração 34
Controle de modificações
[Leon, 2000] Análise de modificação
Leonardo Murta Introdução à Gerência de Configuração 35
Controle de modificações
• A avaliação utilizará a requisição de modificação e o laudo da
análise para tomar a decisão
– A requisição pode ser aceita, rejeitada ou adiada
• A implementação deve ser seguida por testes de unidade
• Durante a verificação, devem ser aplicados testes de sistema
• Após a geração da nova baseline, deve ser decidido se ela será considerada uma nova liberação
Controle de modificações
• Caso especial: Correções emergenciais
– No caso de correções emergenciais, podem ser criados ramos sem a necessidade do processo formal
– Em algum momento esses ramos deverão sofrer junção para a linha principal de desenvolvimento
– Esse procedimento deve estar explicitado no processo!
Leonardo Murta Introdução à Gerência de Configuração 36
Controle de modificações
• Caso especial: Defeitos– Alguns sistemas tratam defeitos de forma diferente
das demais requisições
– A correção de defeitos é um tratamento sintomático
– É importante descobrir o real motivo para o acontecimento do defeito para possibilitar a prevenção de defeitos futuros
– A análise de causa é útil para descobrir falhas no processo de desenvolvimento (e.g. falta de treinamento, padrões inadequados, ferramentas inadequadas)
Leonardo Murta Introdução à Gerência de Configuração 37
Leonardo Murta Introdução à Gerência de Configuração 38
Contabilização da situação
• Tarefas
– Armazenamento das informações geradas
– Propagação dessas informações aos interessados através de relatórios
• Metáfora de conta bancária para item de configuração
• Permite que métricas sejam utilizadas com o intuito de melhoria
do processo e estimativa de custos futuros
• Fornece relatórios gerenciais ad-hoc
Leonardo Murta Introdução à Gerência de Configuração 39
Contabilização da situação
Resultado do relatório no modo tabular no Bugzilla
Leonardo Murta Introdução à Gerência de Configuração 40
Contabilização da situação
Resultado do relatório no modo de gráfico de pizza no Bugzilla
Leonardo Murta Introdução à Gerência de Configuração 41
Contabilização da situação
Resultado da consulta sobre séries no Bugzilla
Leonardo Murta Introdução à Gerência de Configuração 42
Exemplo de ferramentas de controle de modificações
• Livre– Bugzilla– Mantis– Redmine– Trac
• Comercial– ClearQuest (IBM Rational)– JIRA (Atlassian)– StarTeam (Borland)– Synergy/Change (Telelogic)– TeamTrack (Serena)– Team Foundation Server (Microsoft)
Sistema de Gerência de Configuração
Leonardo Murta Introdução à Gerência de Configuração 43
Artefatos
Controle de Versões
Construção e Release
Controle de Modificações
Solicitações
Leonardo Murta Introdução à Gerência de Configuração 44
Auditoria da configuração
• Deve ocorrer ao menos antes de uma liberação (release)
• Tarefas
– Verificação funcional, assegurando que a baseline cumpre o que foi
especificado
– Verificação física, assegurando que a baseline é completa (todos os
itens de configuração especificados)
• Auditorias servem para garantir que os procedimentos e
padrões foram aplicados
Leonardo Murta Introdução à Gerência de Configuração 45
Auditoria da configuração
• A auditoria funcional ocorre através da revisão dos planos, dados,
metodologia e resultado dos teste, para verificar se são satisfatórios
• A auditoria física examina a estrutura de todos os itens de configuração
que compõem a baseline
• A auditoria física é efetuada após a auditoria funcional
• Podem ocorrer auditorias no próprio sistema de GC pelos mantenedores
do plano de GC, para verificar se as políticas e procedimentos estão
sendo cumpridos
Leonardo Murta Introdução à Gerência de Configuração 46
Gerenciamento de releases
• Descrição de como construir, liberar e entregar o sistema
– Linguagem natural (conhecimento)
– Linguagem computacional (automação)
– Manter os descritores e documentos sob gerência de configuração!
• Definição das situações onde o processo pode ser temporariamente
desviado
• Cuidado: Releases muito curtas podem levar a círculo-vicioso de
defeitos...
Gerenciamento de releases
Releases Curtas
+
Testes manuais
+
Equipe pequenaBaixa cobertura
dos testes
Defeitos no
produto final
Necessidade de
novas releases
Solicitações de
correção dos defeitos
Leonardo Murta Introdução à Gerência de Configuração 47
Leonardo Murta Introdução à Gerência de Configuração 48
Exemplo de ferramentas de controle de construção e liberação
• Livre– Ant– NAnt– Make– Maven– Rake
• Comercial– ClearMake (IBM Rational)– MSBuild (Microsoft)– Synergy/CM Object Make (Telelogic)
Analisando mais a fundo uma ferramenta popular...
Leonardo Murta Introdução à Gerência de Configuração 49
Histórico
• Projeto iniciado em 2000
– Iniciativa da CollabNet
– Open-Source
• Intuito de substituir o CVS
– Similar no uso
– Melhor na implementação
• Auto controlado desde agosto de 2001
Leonardo Murta Introdução à Gerência de Configuração 50
Características
• Versionamento de diretórios
• Copia, renomeação e movimentação com histórico
• Check-ins atômicos
• Versionamento de meta-dados
• Acesso via http/https
• Uso extensivo de deltas– Delta de binários
– Delta bidirecional na comunicação cliente/servidor
Leonardo Murta Introdução à Gerência de Configuração 51
Problema da concorrência
Leonardo Murta Introdução à Gerência de Configuração 52
Política pessimista
Leonardo Murta Introdução à Gerência de Configuração 53
Política pessimista
• Problemas administrativos– Bloqueios esquecidos podem atrasar o andamento do projeto
• Problemas de serialização desnecessária– Em alguns casos, as modificações atuam sobre partes
independentes dos arquivos bloqueados
• Falsa sensação de segurança– Dependências semânticas podem cruzar a fronteira de arquivos
• Bloqueios são necessários– Quando se trata de arquivos que não podem ser combinados
Leonardo Murta Introdução à Gerência de Configuração 54
Política otimista (1/2)
Leonardo Murta Introdução à Gerência de Configuração 55
Política otimista (2/2)
Leonardo Murta Introdução à Gerência de Configuração 56
Controle de concorrência no Subversion
• Política pessimista e otimista em conjunto– Qualquer artefato pode ser sujeito a bloqueio– Artefatos podem ser demarcados com “necessita de bloqueio”
• Artefatos bloqueados por um desenvolvedor podem ser editados por outros– O commit dos outros somente ocorrerá depois do término do
bloqueio– Os outros deverão fazer merge
• Artefatos bloqueados podem ser “roubados”– Bloqueio apoia à comunicação– Bloqueio não engessa o processo
Leonardo Murta Introdução à Gerência de Configuração 57
Repositório
• Sistema de arquivos versionado– Check-in equivale a uma foto do sistema de arquivos num dado
momento
• Versionamento global– Número de versão dado por commit
– Identificador implícito de conjunto de modificações
• Algoritmo “Bubble up”– Economia de espaço
– Velocidade na atualização
– Controle do histórico
Leonardo Murta Introdução à Gerência de Configuração 58
Sistema de arquivos tradicional
Leonardo Murta Introdução à Gerência de Configuração 59
Dim
ensã
o E
SPA
ÇO
Sistema de arquivos versionado
Leonardo Murta Introdução à Gerência de Configuração 60
Dim
ensã
o E
SPA
ÇO
Dimensão TEMPO
Versionamento global
• O repositório é mais que um conjunto de arquivos independentes
– Mudança de versionamento de arquivos para versionamento do repositório
– Versão N é o estado do repositório depois do commit N
– “Versão 5 do arquivo X” passa a ser lido como “arquivo X na versão 5 do repositório”
Leonardo Murta Introdução à Gerência de Configuração 61
Comando log
• Fornece um relatório sobre as versões do repositório– Por arquivo– Por commit
• Exibe, para cada versão– Identificação (número da modificação)– Quem (autor)– Quando (data)– Onde (caminhos)– Como (ação nos caminhos)– O que (mensagem)– Por que (número da solicitação de modificação)
Leonardo Murta Introdução à Gerência de Configuração 62
Comando log
Leonardo Murta Introdução à Gerência de Configuração 63
Exemplo
Sintaxe
svn log [-q] [-v] [-r VERSÃO] [URL]
svn log -q https://reuse.cos.ufrj.br/svn/brecho/trunk/build.xml
r92 | ronaldo | 2007-04-01 17:28:55 -0300 (dom, 01 abr 2007)r91 | paulacibele | 2007-03-19 12:53:47 -0300 (seg, 19 mar 2007)r90 | paulacibele | 2007-03-19 12:44:20 -0300 (seg, 19 mar 2007)r51 | marinho | 2006-01-18 19:03:39 -0200 (qua, 18 jan 2006)r47 | alexrd | 2006-01-07 10:44:46 -0200 (sáb, 07 jan 2006)r37 | mlopes | 2005-09-27 00:46:04 -0300 (ter, 27 set 2005)r31 | alexrd | 2005-09-12 11:15:33 -0300 (seg, 12 set 2005)...
Comando log
Leonardo Murta Introdução à Gerência de Configuração 64
Exemplo
Sintaxe
svn log [-q] [-v] [-r VERSÃO] [URL]
svn log -v -r 92 https://reuse.cos.ufrj.br/svn/brecho
r92 | ronaldo | 2007-04-01 17:28:55 -0300 (dom, 01 abr 2007) | 1 lineCaminhos mudados:
M /trunk/build.xmlM /trunk/src/br/ufrj/cos/reuse/biblioteca/category/CategoryUtil.javaA /trunk/src/br/ufrj/cos/reuse/biblioteca/category/Suggestions.javaM /trunk/src/br/ufrj/cos/reuse/biblioteca/category/dao/HibernateCategoryDAO.java
Issue #234: Troca do algoritmo de sugestão de categorias
Algoritmo “Bubble up”
• Mecanismo interno do Subversion para controle do repositório– Entender esse mecanismo ajuda a entender o funcionamento
do Subversion
• Para um dado commit as ações são– Aplicadas nas folhas– Propagadas para os diretórios pais
• Arquivos e diretórios não afetados pelas modificações são preservados
• Algoritmo utilizado para armazenamento– Reverse delta
Leonardo Murta Introdução à Gerência de Configuração 65
Repositório inicial
Leonardo Murta Introdução à Gerência de Configuração 66
Repositório
1
Diretório 1
Arquivo 1
Diretório 2
Arquivo 2
Arquivo 3
Commit: modificação em um único arquivo
Leonardo Murta Introdução à Gerência de Configuração 67
Repositório
1
Diretório 1
Arquivo 1
Diretório 2
Arquivo 2
Arquivo 3 Arquivo 3
Propagação para o diretório pai
Leonardo Murta Introdução à Gerência de Configuração 68
Repositório
1
Diretório 1
Arquivo 1
Diretório 2
Arquivo 2
Arquivo 3
Diretório 2
Arquivo 3
Criação da nova versão
Leonardo Murta Introdução à Gerência de Configuração 69
Repositório
1 2
Diretório 1
Arquivo 1
Diretório 2
Arquivo 2
Arquivo 3
Diretório 2
Arquivo 3
Commit: adição de um novo arquivo
Leonardo Murta Introdução à Gerência de Configuração 70
Repositório
1 2
Diretório 1
Arquivo 1
Diretório 2
Arquivo 2
Arquivo 3
Diretório 2
Arquivo 3
Arquivo 4
Propagação para o diretório pai
Leonardo Murta Introdução à Gerência de Configuração 71
Repositório
1 2
Diretório 1
Arquivo 1
Diretório 2
Arquivo 2
Arquivo 3
Diretório 2
Arquivo 3
Diretório 1
Arquivo 4
Criação da nova versão
Leonardo Murta Introdução à Gerência de Configuração 72
Repositório
1 2
Diretório 1
Arquivo 1
Diretório 2
Arquivo 2
Arquivo 3
Diretório 2
Arquivo 3
3
Diretório 1
Arquivo 4
Cópia “barata”
• O projeto interno do Subversion visa prover cópias “baratas” de diretório– Os dados não são duplicados
– Conceito semelhante a hard-link do unix
– Somente quando há mudanças, o link é quebrado
– Tempo constante gasto para cópias
• Mecanismo utilizado para– Etiquetas (tags)
– Ramos (branches)
Leonardo Murta Introdução à Gerência de Configuração 73
Versão atual do repositório
Leonardo Murta Introdução à Gerência de Configuração 74
Repositório
5
Diretório 1
Arquivo 1
Diretório 2
Arquivo 2
Arquivo 3
Diretório 3
Arquivo 4
Diretório 2 copiado para dentro do Diretório 1 com outro nome
Leonardo Murta Introdução à Gerência de Configuração 75
Repositório
5
Diretório 1
Arquivo 1
Diretório 2
Arquivo 2
Arquivo 3
Diretório 3
Arquivo 4
Diretório 2’
Conteúdo idêntico ao original
Leonardo Murta Introdução à Gerência de Configuração 76
Repositório
5
Diretório 1
Arquivo 1
Diretório 2
Arquivo 2
Arquivo 3
Diretório 3
Arquivo 4
Diretório 2’
Propagação para o diretório pai
Leonardo Murta Introdução à Gerência de Configuração 77
Repositório
5
Diretório 1
Arquivo 1
Diretório 2
Arquivo 2
Arquivo 3
Diretório 1
Diretório 3
Arquivo 4
Diretório 2’
Criação da nova versão
Leonardo Murta Introdução à Gerência de Configuração 78
Repositório
5 6
Diretório 1
Arquivo 1
Diretório 2
Arquivo 2
Arquivo 3
Diretório 1
Diretório 3
Arquivo 4
Diretório 2’
Layout do repositório
• Layout é uma convenção– Permite mais de um projeto por repositório
– Ajuda a organizar cada projeto
• Layout sugerido– Um diretório por projeto na raiz do repositório
• Layout para cada projeto– Um diretório para o ramo principal: trunk
– Um diretório para os ramos: branches
– Um diretório para as etiquetas: tags
Leonardo Murta Introdução à Gerência de Configuração 79
Layout do repositóriohttps://svn.ic.uff.br/
proj1/trunk/branches/tags/
dissertacoes/fulano/
trunk/branches/tags/
beltrano/trunk/branches/tags/
...
Leonardo Murta Introdução à Gerência de Configuração 80
Etiquetas e Ramos
• Etiquetas (tags)– Cópias “baratas” do trunk para o diretório tags
– Troca de nome pelo nome da etiqueta
– Por convenção, nenhuma edição é feita sobre esse diretório copiado
• Ramos (branches)– Cópias “baratas” do trunk para o diretório branches
– Troca de nome pelo nome do ramo
– Edição no diretório copiado
Leonardo Murta Introdução à Gerência de Configuração 81
Comando copy
• Copia um arquivo ou diretório com histórico entre caminhos no repositório ou espaço de trabalho
• Casos típicos– URL URL: cópia executada atomicamente no servidor,
utilizada usualmente para criar etiquetas e ramos– Diretório local diretório local: cópia feita no cliente e adição
(com histórico) agendada para o próximo commit
Leonardo Murta Introdução à Gerência de Configuração 82
Comando copy
Leonardo Murta Introdução à Gerência de Configuração 83
Exemplo
Sintaxe
svn copy ORIGEM DESTINO [-m MENSAGEM]
svn copy dir1 dir2/novo_dir_1
svn copy https://svn.ic.uff.br/proj1/trunkhttps://svn.ic.uff.br/proj1/branches/1.0.x-m “Criação do ramo 1.0.x”
svn copy https://svn.ic.uff.br/proj1/branches/1.0.xhttps://svn.ic.uff.br/proj1/tags/1.0.1-m “Criação da etiqueta 1.0.1”
Espaço de trabalho
• Diretório comum no sistema de arquivos local
• Guarda uma cópia limpa do checkout (.svn) – Permite algumas operações off-line
– Permite transmissão de diffs para o servidor
• Área isolada das modificações de outros desenvolvedores– Suas modificações podem ser publicadas com commit
– Modificações de outros podem ser incorporadas com update
• Um usuário pode ter vários espaços de trabalho para um mesmo projeto
Leonardo Murta Introdução à Gerência de Configuração 84
Comando check-out
• Constrói um espaço de trabalho a partir de uma versão do repositório (ou parte dela)
Leonardo Murta Introdução à Gerência de Configuração 85
Comando check-out
Leonardo Murta Introdução à Gerência de Configuração 86
Exemplo
Sintaxe
svn checkout [-r VERSÃO] URL [CAMINHO]
svn checkout https://svn.ic.uff.br/proj1/trunk
svn checkout -r 15 https://svn.ic.uff.br/proj1/trunk
svn checkout https://svn.ic.uff.br/proj1/tags/1.0.3 rel1.0.3
Comando commit
• Envia modificações do espaço de trabalho para o repositório– Detecta automaticamente o que mudou
– Libera todos os bloqueios
– Aplica a modificação de forma atômica no repositório
• Pode não conseguir enviar caso algum outro usuário tenha dado commit– Necessário um update
Leonardo Murta Introdução à Gerência de Configuração 87
Comando commit
Leonardo Murta Introdução à Gerência de Configuração 88
Exemplo
Sintaxe
svn commit [-m MENSAGEM] [CAMINHO]
svn commit -m “Adição da versão 1.4.5 do modelo”
svn commit -m “Issue #34: Correção de erro de digitação” src
Comando update
• Atualiza o espaço de trabalho com as últimas modificações existentes no repositório
• Pode encontrar conflitos durante a atualização– É importante verificar cada um dos arquivos atualizados
• Ações sobre o espaço de trabalho– Adição de arquivos (A)– Remoção de arquivos (D)– Atualização de arquivos (U)– Arquivos com conflito (C)– Arquivos combinados (G)
Leonardo Murta Introdução à Gerência de Configuração 89
Comando update
Leonardo Murta Introdução à Gerência de Configuração 90
Exemplo
Sintaxe
svn update [-r VERSÃO] [CAMINHO]
svn update
svn update -r 12
svn update dir1
Comportamento dos comandos
Arquivo
modificado
localmente
Arquivo
modificado no
repositório
Comando
commit
Commando update
Não Não Nenhuma
ação
Nenhuma ação
Não Sim Nenhuma
ação
Versão local substituída
pela versão do repositório
Sim Não Publica a
versão local
no repositório
Nenhuma ação
Sim Sim Falha,
avisando que
o arquivo está
desatualizado
Versão local combinada
com a versão do repositório
Introdução à Gerência de Configuração 91Leonardo Murta
Ciclo básico de trabalho
Leonardo Murta Introdução à Gerência de Configuração 92
Construção do
espaço de trabalho
svn checkout
svn update
svn switch
Implementação
svn add
svn delete
svn copy
svn move
svn lock
svn blame
svn log
Verificação
svn status
svn diff
svn revert
Integração
svn update
svn resolved
svn commit
Junção de ramos
• Deve ser feita em um espaço de trabalho limpo
– Check-out do destino da junção
• Deve ser entendida como diff & apply
• Diff é dependente de ordem
– Diff(A, B): ações necessárias para transformar o caminho A no caminho B
• O diff pode atuar tanto no espaço quanto no tempo
– Espaço: diff entre dois diretórios (copiados de um lugar comum)
– Tempo: diff entre duas versões de um mesmo diretório
Leonardo Murta Introdução à Gerência de Configuração 93
Merge no tempo
• Normalmente usado para ramos
Leonardo Murta Introdução à Gerência de Configuração 94
Espaço de trabalho
apply: ∆1
∆1 = diff(v4, v10)
trunk
1 2
3
6 8 11
124 5 7 109
13 14 15
branches/1.0.x
Merge no espaço
• Normalmente usado para etiquetas
Leonardo Murta Introdução à Gerência de Configuração 95
1.0.0 1.0.1
Espaço de trabalho
apply: ∆1
∆1 = diff(1.0.0, 1.0.1)
trunk
branches/1.0.x
tags
1 2
3 4
6 8 11
125 7 109
13 14 15
Comando merge
• Aplica a diferença entre dois caminhos no espaço de trabalho
• svn merge A B– Calcula as ações que precisam ser feitas para transformar o
caminho A no B– Aplica essas ações no espaço de trabalho
Leonardo Murta Introdução à Gerência de Configuração 96
Comando merge
Leonardo Murta Introdução à Gerência de Configuração 97
Exemplo
Sintaxesvn merge [-c VERSÃO | -r VERSÃO1:VERSÃO2] CAMINHOsvn merge CAMINHO1 CAMINHO2
svn merge -c 23 https://svn.ic.uff.br/proj1/branches/1.0.x
svn merge -c -23 https://svn.ic.uff.br/proj1/branches/1.0.x
svn merge -r 23:29 https://svn.ic.uff.br/proj1/branches/1.0.x
svn merge https://svn.ic.uff.br/proj1/tags/1.0.1https://svn.ic.uff.br/proj1/tags/1.0.2
Ciclo básico de junção
Leonardo Murta Introdução à Gerência de Configuração 98
Construção do
espaço de trabalho
svn checkout
svn update
svn switch
Junção
svn merge
svn blame
svn log
Verificação
svn status
svn diff
svn revert
Integração
svn update
svn resolved
svn commit
Propriedades
• Cada diretório ou arquivo pode ter metadados anexados a ele
– Tuplas <nome, valor>
– Versionados
• Algumas propriedades built-in
– svn:mime-type: tipo do arquivo
– svn:ignore: elementos que não devem ser versionados em um diretório
– svn:needs-lock: indica que o arquivo precisa de política de controle de concorrência pessimista
Leonardo Murta Introdução à Gerência de Configuração 99
Principais Referências Bibliográficas
• Alexis Leon, “A Guide to Software ConfigurationManagement”, Artech House Publishers, 2000.
• Anne Hass, “Configuration Management Principles andPractices”, Boston, MA, Pearson Education, Inc.
• Dart, S., 1991, “Concepts in Configuration Management Systems”, International Workshop on Software Configuration Management (SCM), Trondheim, Norway(June), pp. 1-18.
• Pressman, R. S. (1997). “Software Engineering: A Practitioner's Approach”, McGraw-Hill.
• http://svnbook.red-bean.com/en/1.4• http://subversion.tigris.org/design.html
Leonardo Murta Introdução à Gerência de Configuração 100