svn e processos de controle de código

SVN E PROCESSOS DE

CONTROLE DE CÓDIGO

DEFININDO O CONTROLE

� Como podemos ver na citação do próprio documento oficial, é muito facil acontecer a documento oficial, é muito facil acontecer a sobrescrita por acidente.

� É mais fácil, quando as cópias em desenvolvimento se misturam a de produção e de referência. Será explicado o por quê nas situações de exemplo.

MODELOS DE CONTROLE

� Os modelos de controle devem ser um dos primeiros tópicos ao discutir-se a implantação do SVN. São eles:

1. Copy-Modify-Merge ou Copiando-Modificando-Unificando.Vamos simplificar o nome desse Unificando.Vamos simplificar o nome desse modelo para Merge.

2. Lock-Modify-Unlock ou Bloqueando-Modificando-Liberando. Vamos simplificar o nome desse modelo para Lock.

PERSONAGENS

Responsável pela validação.

Grupo de desenvolvedores

Desenvolvedor

MAU GERENCIAMENTO DOS ARQUIVOS EM

PRODUÇÃO

Não criada referência a versão.

Produção(Build)

Repositório de desenvolvimento(Trunk)

REFERENCIANDO ARQUIVOS DE PRODUÇÃO

Produção(Build)

Repositório de produção(Tag)

KANBAN

� Devemos ter um sistema de versionamento que suporte alterações de usuários diferentes em um mesmo arquivo ao mesmo tempo.

� Isso significa que no nosso kanban ao lado poderiamos ter desenvolvendores ter desenvolvendores diferentes na seção doing alterando o mesmo arquivo.

� Nesse sentido ter um processo visual de quais arquivos estão sendo alterados pode ajudar a resolver conflitos.

RESOLUÇÃO DE CONFLITOS

Repositório de

Edit Conflicts

Resolução do conflito

Repositório de

desenvolvimento(Trunk)

Merge

BRANCHING

Repositório de ramificações(branches)

/projeto_devn

/projeto_dev1

Merge

Repositório de produção(Tag)

O administrador pode realizar o merge necessário e liberar a versão

para produção(Tag).

BRANCHING (P2)

/projeto_dev2

/projeto_dev1Merge

/projeto_devn

Versões que carregam necessidade de testes e validações devem ser

encaminhadas para branches.

Repositório de ramificações(branches)

LOCK


Lock(bloqueia)


Commit- release(publica e libera)

Pode-se utilizar o Lock(bloqueio) para pequenas alterações.

Em um kanban poderíamos acompanhar a demanda desses arquivos

para outras modificações.

QUEBRANDO O VERSIONAMENTO

� Utilizar pastas do projeto não versionadas quebra o versionamento.

� Se você precisa ramificar (colocar em uma pasta avulsa) a sua uma pasta avulsa) a sua cópia local (você só deve ter uma*) o SVN tem um repositório só para isso.

� A situação seguinte exemplifica essas afirmações.

QUEBRANDO O VERSIONAMENTO


Quebra de versionamento

QUEBRANDO O VERSIONAMENTO (P2)


Quebra de versionamento

MOTIVOS PARA SE TRABALHAR COM O

REPOSITÓRIO DE RAMIFICAÇÕES (BRANCHES)

1. Banir mais de uma cópia local(principalmente as não versionadas) nas máquinas clientes do SVN. Com isso evitamos subscrita.

2. Separar versões de teste de versões de produção.3. Diminuir a necessidade de várias validações em uma

única versão.única versão.4. Agilizar a liberação de versões para testes.5. Evitar que funcionalidades que não estão

finalizadas/concluídas sejam submetidas ao cliente.6. Evitar que projetos longos estejam presente somente

na máquina cliente, durante a fase de implementação.

7. Resolver provisoriamente alterações concorrentes no mesmo arquivo, afim de evitar conflitos.

UTILIZANDO O BRANCHES. RECURSOS DO SVN.

Repositório de desenvolvimento(Trunk) Repositório de ramificações(branches)

/projeto_devn

/projeto_dev1

Alterna

Mantém cópia única

UTILIZANDO O BRANCHES.

Repositório de desenvolvimento(Trunk) Repositório de ramificações(branches)

/projeto_devn

/projeto_dev1

Publica

MERGE

MITOS RELACIONADOS AO UPDATE

� Conforme vimos o update sobrescreve com a versão mais atual, as suas cópias locais. Se a versão do repositório foi publicada erroneamente, você receberá esse arquivo.

� Se você fez alterações que não estão publicadas o updatetentará realizar o merge caso as linhas alteradas não afetem suas modificações.afetem suas modificações.

� Caso contrário existirá um conflito, e você não perderá nada, inclusive por que o SVN guardará sua cópia local com o nome .mine, conforme você pode ver na imagem ao lado.

� A partir daí você decide sobre o conflito. O sistema não é adivinho.

ARQUIVOS GERADOS NO CONFLITO

� filename.ext.mine� Este é seu arquivo tal como existia em sua cópia local antes

de tê-la atualizado - ou seja, sem indicações de conflito. Este arquivo contém as modificações mais recentes e nada mais.

� filename.ext.rREVANT� filename.ext.rREVANT� Este é o arquivo que serviu de revisão BASE antes de

atualizar sua cópia local. Ou seja, é o arquivo que você assinalou para controlar antes de efetuar as modificações.

� filename.ext.rNOVAREV� Este é o arquivo que o cliente Subversion acabou de receber

do servidor quando você atualizou sua cópia local. Este arquivo corresponde à revisão HEAD do repositório.

CONCLUSÕES

� Usar o SVN com pastas não versionadas ajuda a quebrar o versionamento.

� É necessário obter a cultura de que todos os arquivos de projeto devem estar sobre versionamento.versionamento.

� Devemos conhecer o que equipe está fazendo afim até de evitar re-trabalho e conflitos.

� Podemos usar o SVN afim de resolver problemas conhecendo melhor o como seu uso foi pensado.

FIMAutor: Cláudio da Costa ApolônioTécnologo em Processamento de Dados – Fatec-BS(Rubens Lara)

Pós-Graduando em Gerencimento de Projetos – Senac-SP (Santos)

svn e processos de controle de código

Technology