Introdução à Gerência de Configuração. Leonardo Gresta Paulino Murta

(1)

Introdução à

Gerência de Configuração

Leonardo Gresta Paulino Murta

leomurta@ic.uff.br

(2)

Introdução

• A Engenharia de Software...

– Abordagem disciplinada para o desenvolvimento de

software

(3)

Introdução

• Ponto em comum nas metodologias:

– refinamentos sucessivos de artefatos

Leonardo Murta Introdução à Gerência de Configuração 3

(4)

Mas aonde ficam esses artefatos?

Tarefas de

Engenharia de

Software

Artefato

novo

Repositório

Artefato

modificado

Artefato

(5)

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

(6)

Tipos de repositórios

Desenvolvimento

Liberação

Implantação

Produção

Repositório de fontes

(7)

Potenciais diferenças

Repositório de

fontes

Repositório de

executáveis

G R A N U L A R I D A D E

Fina

Grossa

M O M E N T O

Desenvolvimento

Produção

A C E S S O

Edição

Leitura

L O C A L I Z A Ç Ã O

Contexto

Busca

(8)

Cenário de utilização

Repositório de

fontes

Repositório de

executáveis

(9)

Principais sistemas de

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)

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

(10)

Principais sistemas de

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)

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

Nosso foco aqui

no curso...

(11)

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.)

(12)

Item de configuração

• Agregação de hardware e/ou software que será

passível de gerência de configuração e tratado

como um elemento único

• Tipos de ICs

– Produtos de trabalho do projeto

– Produtos de trabalho de processos

• Exemplos: plano de GC, requisitos, modelos,

código-fonte, etc.

(13)

Versão

• Instâncias de um mesmo item de configuração

que diferem entre si em algo (sinônimo: revisões)

IC

1.0 IC

1.1 IC

1.2 IC

1.1.1 IC

1.1.2 IC

1.3 IC

2.0 IC

1.4 IC

2.1

(14)

Sistema de Gerência de Configuração

Versão 1

Versão 2

Versão 3

Versão 4

Versão 5

(15)

Sistema de Gerência de Configuração

Versão 1

Versão 2

Versão 3

Versão 4

(16)

Sistema de Gerência de Configuração

Versão 1

Versão 2

Versão 3

Versão 4

Versão 5

(17)

Configuração

• Um conjunto de versões de Itens de Configuração

(IC), onde existe somente uma versão selecionada

para cada IC do conjunto

• Uma configuração pode ser vista como um IC

composto de outros ICs

• Exemplos

– Configuração do sistema

– Configuração do processo

– Configuração do módulo X

– Configuração dos requisitos do sistema

– Configuração do código fonte

(18)

Configuração x versão

• Genericamente

– O sistema S é composto pelos arquivos X, Y e Z

• Concretamente

– A configuração 5 do sistema S é composta pela versão 2 do

arquivo X, versão 4 do arquivo Y e versão 6 do arquivo Z

Configuração

Versão

IC composto

IC primitivo

(19)

Configuração x versão

IC composto

Conf. 1

Conf. 2

Conf. 3

IC primitivo 1

IC primitivo 2

IC primitivo 3

V.1

V.2

V.3

V.4

V.1

V.2

V.1

V.2

V.3

(20)

Controle de versões

Repositório

Item de

Configuração

Como armazenar?

(21)

Mecanismos de 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

(22)

Controle de concorrência

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

(23)

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)

(24)

Junção

• Processo de migração de

– Espaços de trabalho

– Ramos

Linha 1

Linha 2

Linha 3

Linha 1’

Linha 2

<Linha 1> ou <Linha 1’>?

Linha 2

<Linha 3> ou nada?

Linha 1

Linha 2

Linha 3

Linha 1’

Linha 2

Linha 1’

Linha 2

Linha 3

Linha 1

Linha 2

(25)

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

Exemplo

(junção no Eclipse)

(26)

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

(27)

Baseline (níveis de controle)

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

(28)

Baseline (níveis de controle)

Req.

Análise Projeto

1 Inform.

-

Formal

Inform.

Formal

2 -

-

Inform.

-

Formal

Inform.

Requisito 1

Análise

Baseline 1:

Projeto

•An. Req. 1

Requisito 2

Análise

Projeto

Tempo

Baseline 2:

•An. Req. 1

•Pr. Req. 1

•An. Req. 2

(29)

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

(30)

Controle de modificações

(31)

Controle de modificações

(32)

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

(33)

Controle de modificações

(34)

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á

(35)

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!

(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)

(37)

Exemplo de ferramentas de controle de

versões

• Livre

– Aegis

– Bazaar

– CVS

– Git

– Mercurial

– Subversion

• Comercial

– BitKeeper (BitMover)

– ClearCase (IBM Rational)

– Perforce

– PVCS (Serena)

– StarTeam (Borland)

– Synergy/CM (Telelogic)

– Visual SourceSafe (Microsoft)

(38)

Exemplo de ferramentas de controle de

modificações

• Livre

– Bugzilla

– Mantis

– Roundup

– Scarab

– Trac

• Comercial

– ClearQuest (IBM Rational)

– JIRA (Atlassian)

– StarTeam (Borland)

– Synergy/Change (Telelogic)

– TeamTrack (Serena)

(39)

Analisando mais a fundo uma

ferramenta popular...

(40)

Histórico

• Projeto iniciado em 2000

– Iniciativa da CollabNet

– Open-Source

• Intuito de substituir o CVS

– Similar no uso

– Melhor na implementação

(41)

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

(42)

(43)

Política pessimista

(44)

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

(45)

Política otimista (1/2)

(46)

(47)

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

(48)

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

(49)

Sistema de arquivo convencional

Dim

e

n

s

ã

o

ESP

AÇO

(50)

Sistema de arquivo versionado

Dim

e

n

s

ã

o

ESP

AÇO

Dimensão TEMPO

(51)

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”

(52)

Versionamento global

Repositório (versão 1)

Arquivo1 (versão 1)

Arquivo2 (versão 1)

Arquivo3 (versão 1)

Repositório (versão 2)

Arquivo1 (versão 2)

Arquivo2 (versão 1)

Arquivo3 (versão 1)

Repositório (versão 0)

1º commit

2º commit

Repositório (versão 3)

Arquivo1 (versão 2)

Arquivo2 (versão 3)

Arquivo3 (versão 1)

Arquivo4 (versão 3)

Repositório (versão 4)

Arquivo1 (versão 4)

Arquivo2 (versão 3)

Arquivo3 (versão 4)

Arquivo4 (versão 3)

4º commit

3º commit

Arquivo1

Versão 1

Versão 2

Versão 4

Arquivo2

Versão 1

Versão 3

Arquivo3

Versão 1

Versão 4

Arquivo4

Versão 3

(53)

Versionamento global

Repositório (versão 1)

Arquivo1 (versão 1)

Arquivo2 (versão 1)

Arquivo3 (versão 1)

Repositório (versão 2)

Arquivo1 (versão 2)

Arquivo2 (versão 1)

Arquivo3 (versão 1)

Repositório (versão 0)

1º commit

2º commit

Repositório (versão 3)

Arquivo1 (versão 2)

Arquivo2 (versão 3)

Arquivo3 (versão 1)

Arquivo4 (versão 3)

Repositório (versão 4)

Arquivo1 (versão 4)

Arquivo2 (versão 3)

Arquivo3 (versão 4)

Arquivo4 (versão 3)

4º commit

3º commit

1º commit

Arquivo1 adicionado

Arquivo2 adicionado

Arquivo3 adicionado

2º commit

Arquivo1 modificado

3º commit

Arquivo2 modificado

Arquivo4 adicionado

Relatório por commit

4º commit

Arquivo1 modificado

Arquivo3 modificado

(54)

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)

(55)

Comando log

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)

...

(56)

Comando log

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 line

Caminhos mudados:

M /trunk/build.xml

M /trunk/src/br/ufrj/cos/reuse/biblioteca/category/CategoryUtil.java

A /trunk/src/br/ufrj/cos/reuse/biblioteca/category/Suggestions.java

M /trunk/src/br/ufrj/cos/reuse/biblioteca/category/dao/HibernateCategoryDAO.java

Issue #234: Troca do algoritmo de sugestão de categorias

(57)

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

(58)

Repositório inicial

Repositório

1 Diretório 1

Arquivo 1

Diretório 2

Arquivo 2

Arquivo 3

(59)

Commit: modificação em um único arquivo

Repositório

1 Diretório 1

Arquivo 1

Diretório 2

Arquivo 2

Arquivo 3

(60)

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

(61)

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

(62)

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

(63)

Propagação para o diretório pai

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

(64)

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

3 Diretório 1

Arquivo 4

(65)

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)

(66)

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

(67)

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’

(68)

Conteúdo idêntico 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’

(69)

Propagação para o diretório pai

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’

(70)

Criação da nova versão

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’

(71)

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

(72)

Layout do repositório

https://svn.ic.uff.br/

proj1/

trunk/

branches/

tags/

dissertacoes/

fulano/

trunk/

branches/

tags/

beltrano/

trunk/

branches/

tags/

...

(73)

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

(74)

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

(75)

Comando copy

Exemplo

Sintaxe

svn copy ORIGEM DESTINO [-m MENSAGEM]

svn copy dir1 dir2/novo_dir_1

svn copy https://svn.ic.uff.br/proj1/trunk

https://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.x

https://svn.ic.uff.br/proj1/tags/1.0.1

-m “Criação da etiqueta 1.0.1”

(76)

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

(77)

Comando check-out

• Constrói um espaço de trabalho a partir de uma

versão do repositório (ou parte dela)

(78)

Comando check-out

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

(79)

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

(80)

Comando commit

Exemplo

Sintaxe

svn commit [-m MENSAGEM] [CAMINHO]

svn commit -m “Adição da versão 1.4.5 do modelo”

(81)

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)

(82)

Comando update

Exemplo

Sintaxe

svn update [-r VERSÃO] [CAMINHO]

svn update

svn update -r 12

svn update dir1

(83)

Comportamento dos comandos

Arquivo

modificado

localmente

Arquivo

modificado no

repositório

Comando

commit

Commando update

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

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

(84)

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

(85)

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

(86)

Merge no tempo

• Normalmente usado para ramos

Espaço de trabalho

apply:

∆

₁

∆

₁

= diff(v4, v10)

trunk









1

2

3

6

8

11

12

4

5

7

9

10 13 14 15

branches/1.0.x

(87)

Merge no espaço

• Normalmente usado para etiquetas

1.0.0

1.0.1 Espaço de trabalho

apply:

∆

₁

∆

₁

= diff(1.0.0, 1.0.1)

trunk

branches/1.0.x









1

2

3

4

6

8

11

12

5

7

9

10 13 14 15

(88)

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

(89)

Comando merge

Exemplo

Sintaxe

svn merge [-c VERSÃO | -r VERSÃO1:VERSÃO2] CAMINHO

svn 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.1

(90)

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

(91)

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

(92)

Principais Referências Bibliográficas

• Alexis Leon, “A Guide to Software Configuration

Management”, Artech House Publishers, 2000.

• Anne Hass, “Configuration Management Principles and

Practices”, 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

(93)

Introdução à

Gerência de Configuração

Leonardo Gresta Paulino Murta

leomurta@ic.uff.br