Introduçãoà GerênciadeConﬁguraçãoleomurta/courses/2012.2/es2/aula5.pdf · Introdução • Pontoemcomumnasmetodologias:** – reﬁnamentossucessivosdeartefatos

Introdução à Gerência de Configuração

Leonardo Gresta Paulino Murta [email protected]

Introdução •  A Engenharia de SoCware...

– Abordagem disciplinada para o desenvolvimento de soCware

– 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


hKp://www.colegiosaofrancisco.com.br

Mas onde ficam esses artefatos?


Tarefas de Engenharia de

SoCware

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


Gerência de Configuração

Desenvolvimento Liberação Implantação Produção


Gerência de Configuração

Gerência de configuração de soCware é uma disciplina para o controle da evolução de sistemas de so3ware (Susan Dart, 1991)


Histórico •  Anos 50

–  GC para produção de aviões de guerra e naves espaciais •  Anos 60 e 70

–  Surgimento de GCS (S = SoCware) –  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


Versão 1

Versão 2

Versão 3

Versão 4

Versão 5



Versão 1

Versão 2

Versão 3

Versão 4

Versão 5



Versão 1

Versão 2

Versão 3

Versão 4

Versão 5



Artefatos

Controle de Versões

Construção e Release

Controle de Modificações

Solicitações


Sistema x Funções de GC

Ambiente de Desenvolvimento de Software

Identificação Controle Contabilização Avaliação Liberação



Gerenciamento de Construção

Sistemas:

Processos:

Espaço de trabalho:

Perspectiva de integração

Perspectiva gerencial

Perspectiva de desenvolvimento

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, uma ferramenta de gerenciamento de construção e release (make, ant, maven, etc.)

3.  Apresentar, na próxima aula, o que é integração coninua, dando algum exemplo usando uma ferramenta (Cruise Control, Apache Conjnuum, Hudson, etc.)




Artefatos




Solicitações

Controle de versões


Armazenamento? Colaboração? Consulta?

Topologia?

Topologia


Repositório

Espaço de Trabalho

Centralizado Distribuído

chec

k-in

/ co

mm

it

check-out / update Repositório

Espaço de Trabalho ch

eck-

in

check-out / update

Repositório

Espaço de Trabalho

clone / pull

push

Armazenamento


v.3

v.2

v.1

Completo

delta 1à2

v.1

Forward

delta 2à3

delta 3à2

v.3

Reverse

delta 2à1

In-line

v.1 v.2/3

v.1/2 v.3

Colaboração


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


Repositório (versão 1) Artefato1 (versão 1) 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)

Artefato1 Versão 1 Versão 2 Versão 4

Artefato2 Versão 1 Versão 3

Artefato3 Versão 1 Versão 4

Artefato4 Versão 3

Consulta por artefato 1ª modificação

2ª modificação 4ª modificação 3ª modificação

Consulta




Repositório (versão 0)

1ª modificação

2ª modificação



4ª modificação 3ª modificação

1ª modificação Artefato1 adicionado Artefato2 adicionado Artefato3 adicionado

2ª modificação Artefato1 modificado

3ª modificação Artefato2 modificado Artefato4 adicionado

Consulta por modificação

4ª modificação Artefato1 modificado Artefato3 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 para a linha principal de desenvolvimento

–  A migração pode ser complicada no caso de isolamento longo •  Caracterísjcas dos ramos se comparados a espaços de trabalho –  comparjlhados 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)



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 RC2 Evolução Evolução Desenv.

Correção Correção Correção

Junção •  Processo de migração de

– Espaços de trabalho – Ramos


ABC DEF GHI

JKL DEF

ABC ou JKL? DEF GHI ou nada?

2-‐way merge

Junção •  Processo de migração de

– Espaços de trabalho – Ramos


ABC DEF GHI

JKL DEF

ABC DEF

JKL DEF GHI

3-‐way merge

Introdução à Gerência de Configuração 25

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 Rajonal) –  Perforce –  PVCS (Serena) –  StarTeam (Borland) –  Synergy/CM (Telelogic) –  Team Foundajon Server (MicrosoC)




Artefatos




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 (funcjonal) –  Projeto (allocated) –  Implementação (product)

•  Momento de criar: balanceamento entre controle e burocracia


Baseline (níveis de controle)


Coordenação c/ auditoria Controle

Pré baseline: • Informal • Sem requisição • Sem aprovação • Sem verificação • Ágil • Ad-‐hoc

Pós baseline: • Formal • Com requisição • Com aprovação • Com verificação • Burocrájco • Planejado e Controlado

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.


Requisito 1 Análise Projeto Baseline 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



Controle de modificações

[Leon, 2000] Requisição de modificação



[White, 2000] Janela de criação de formulários do ClearQuest


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íjcas, fatais, não fatais, cosméjcas)

•  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



[Leon, 2000] Análise de modificação


Controle de modificações •  A avaliação ujlizará 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!


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ájco – É importante descobrir o real mojvo para o acontecimento do defeito para possibilitar a prevenção de defeitos futuros

– A análise de causa é újl para descobrir falhas no processo de desenvolvimento (e.g. falta de treinamento, padrões inadequados, ferramentas inadequadas)



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 ujlizadas com o intuito de melhoria do processo e esjmajva de custos futuros

•  Fornece relatórios gerenciais ad-‐hoc


Contabilização da situação

Resultado do relatório no modo tabular no Bugzilla


Contabilização da situação

Resultado da consulta sobre séries no Bugzilla


Exemplo de ferramentas de controle de modificações

•  Livre –  Bugzilla –  Manjs –  Redmine –  Trac

•  Comercial –  ClearQuest (IBM Rajonal) –  JIRA (Atlassian) –  StarTeam (Borland) –  Synergy/Change (Telelogic) –  TeamTrack (Serena) –  Team Foundajon Server (MicrosoC)



Artefatos




Solicitações


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 ~sica, assegurando que a baseline é completa (todos os itens de configuração especificados)

•  Auditorias servem para garanjr que os procedimentos e padrões foram aplicados


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 sajsfatórios

•  A auditoria Asica examina a estrutura de todos os itens de configuração que compõem a baseline

•  A auditoria ~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íjcas e procedimentos estão sendo cumpridos


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 pequena Baixa cobertura

dos testes

Defeitos no produto final

Necessidade de novas releases

Solicitações de correção dos defeitos



Exemplo de ferramentas de controle de construção e liberação

•  Livre – Ant – NAnt – Make – Maven – Rake

•  Comercial – ClearMake (IBM Rajonal) – MSBuild (MicrosoC) – Synergy/CM Object Make (Telelogic)

Analisando mais a fundo uma ferramenta popular...


Histórico •  Projeto iniciado em 2000

–  Iniciajva da CollabNet – Open-‐Source

•  Intuito de subsjtuir o CVS – Similar no uso – Melhor na implementação

•  Auto controlado desde agosto de 2001


Caracterísjcas •  Versionamento de diretórios •  Copia, renomeação e movimentação com histórico •  Check-‐ins atômicos •  Versionamento de meta-‐dados •  Acesso via hKp/hKps •  Uso extensivo de deltas

– Delta de binários – Delta bidirecional na comunicação cliente/servidor


Problema da concorrência


Políjca pessimista


Políjca pessimista •  Problemas administrajvos

–  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ânjcas podem cruzar a fronteira de arquivos

•  Bloqueios são necessários –  Quando se trata de arquivos que não podem ser combinados


Políjca ojmista (1/2)


Políjca ojmista (2/2)


Controle de concorrência no Subversion

•  Políjca pessimista e ojmista 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


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 –  Idenjficador implícito de conjunto de modificações

•  Algoritmo “Bubble up” –  Economia de espaço –  Velocidade na atualização –  Controle do histórico


Sistema de arquivos tradicional


Dimen

são ESPA

ÇO

Sistema de arquivos versionado


Dimen

são ESPA

Ç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”


Comando log •  Fornece um relatório sobre as versões do repositório

–  Por arquivo –  Por commit

•  Exibe, para cada versão –  Idenjficaçã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)


Comando log


Exemplo

Sintaxe svn log [-‐q] [-‐v] [-‐r VERSÃO] [URL]

svn log -‐q hKps://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


Exemplo

Sintaxe svn log [-‐q] [-‐v] [-‐r VERSÃO] [URL]

svn log -‐v -‐r 92 hKps://reuse.cos.ufrj.br/svn/brecho r92 | ronaldo | 2007-‐04-‐01 17:28:55 -‐0300 (dom, 01 abr 2007) | 1 line Caminhos mudados: M /trunk/build.xml M /trunk/src/br/ufrj/cos/reuse/biblioteca/category/CategoryUjl.java A /trunk/src/br/ufrj/cos/reuse/biblioteca/category/Suggesjons.java M /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 ujlizado para armazenamento –  Reverse delta


Repositório inicial


Repositório 1

Diretório 1

Arquivo 1

Diretório 2

Arquivo 2

Arquivo 3

Commit: modificação em um único arquivo


Repositório 1

Diretório 1

Arquivo 1

Diretório 2

Arquivo 2

Arquivo 3 Arquivo 3

Propagação para o diretório pai


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


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


Repositório 1 2

Diretório 1

Arquivo 1

Diretório 2

Arquivo 2

Arquivo 3

Diretório 2

Arquivo 3

Arquivo 4



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



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 ujlizado para – Ejquetas (tags) – Ramos (branches)


Versão atual do repositório


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


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ênjco ao original


Repositório 5

Diretório 1

Arquivo 1

Diretório 2

Arquivo 2

Arquivo 3

Diretório 3

Arquivo 4

Diretório 2’



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’



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 ejquetas: tags


Layout do repositório hKps://svn.ic.uff.br/ proj1/ trunk/ branches/ tags/ dissertacoes/ fulano/ trunk/ branches/ tags/ beltrano/ trunk/ branches/ tags/ ...


Ejquetas e Ramos •  Ejquetas (tags)

– Cópias “baratas” do trunk para o diretório tags – Troca de nome pelo nome da ejqueta – 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


Comando copy •  Copia um arquivo ou diretório com histórico entre caminhos no repositório ou espaço de trabalho

•  Casos ipicos –  URL à URL: cópia executada atomicamente no servidor, ujlizada usualmente para criar ejquetas 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


Comando copy


Exemplo

Sintaxe svn copy ORIGEM DESTINO [-‐m MENSAGEM]

svn copy dir1 dir2/novo_dir_1 svn copy hKps://svn.ic.uff.br/proj1/trunk hKps://svn.ic.uff.br/proj1/branches/1.0.x -‐m “Criação do ramo 1.0.x” svn copy hKps://svn.ic.uff.br/proj1/branches/1.0.x hKps://svn.ic.uff.br/proj1/tags/1.0.1 -‐m “Criação da ejqueta 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


Comando check-‐out •  Constrói um espaço de trabalho a parjr de uma versão do repositório (ou parte dela)


Comando check-‐out


Exemplo

Sintaxe svn checkout [-‐r VERSÃO] URL [CAMINHO]

svn checkout hKps://svn.ic.uff.br/proj1/trunk svn checkout -‐r 15 hKps://svn.ic.uff.br/proj1/trunk svn checkout hKps://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 automajcamente 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


Comando commit


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 úljmas 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)


Comando update


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 91 Leonardo Murta

Ciclo básico de trabalho


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 desjno 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


Merge no tempo •  Normalmente usado para ramos


Espaço de trabalho

apply: ∆1

∆1 = diff(v4, v10)

trunk

� �

�

�

1 2

3

6 8 11

12 4 5 7 10 9

13 14 15

branches/1.0.x

Merge no espaço •  Normalmente usado para ejquetas


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

12 5 7 10 9

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


Comando merge


Exemplo

Sintaxe svn merge [-‐c VERSÃO | -‐r VERSÃO1:VERSÃO2] CAMINHO svn merge CAMINHO1 CAMINHO2

svn merge -‐c 23 hKps://svn.ic.uff.br/proj1/branches/1.0.x svn merge -‐c -‐23 hKps://svn.ic.uff.br/proj1/branches/1.0.x svn merge -‐r 23:29 hKps://svn.ic.uff.br/proj1/branches/1.0.x svn merge hKps://svn.ic.uff.br/proj1/tags/1.0.1 hKps://svn.ic.uff.br/proj1/tags/1.0.2

Ciclo básico de junção


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: jpo 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íjca de controle de concorrência pessimista


Principais Referências Bibliográficas •  Alexis Leon, “A Guide to SoCware Configurajon Management”, Artech House Publishers, 2000.

•  Anne Hass, “Configurajon Management Principles and Pracjces”, Boston, MA, Pearson Educajon, Inc.

•  Dart, S., 1991, “Concepts in Configurajon Management Systems”, Internajonal Workshop on SoCware Configurajon Management (SCM), Trondheim, Norway (June), pp. 1-‐18.

•  Pressman, R. S. (1997). “SoCware Engineering: A Pracjjoner's Approach”, McGraw-‐Hill.

•  hKp://svnbook.red-‐bean.com/en/1.4 •  hKp://subversion.jgris.org/design.html


Introdução à Gerência de Configuração

Leonardo Gresta Paulino Murta [email protected]

Introdução*à Gerênciade*Conﬁguração*leomurta/courses/2012.2/es2/aula5.pdf · Introdução* • Ponto*em*comum*nas*metodologias:** – reﬁnamentos*sucessivos*de*artefatos*

Documents

Introduçãoà GerênciadeConﬁguraçãoleomurta/courses/2012.2/es2/aula5.pdf · Introdução • Pontoemcomumnasmetodologias:** – reﬁnamentossucessivosdeartefatos