Este documento discute os processos de controle de código no SVN, incluindo modelos de controle como Copy-Modify-Merge e Lock-Modify-Unlock, personagens envolvidos, problemas de gerenciamento de arquivos em produção, referenciando arquivos de produção, resolução de conflitos, branching e motivos para usar branching.

1. SVN E PROCESSOS DE
CONTROLE DE CÓDIGO

2. DEFININDO O CONTROLE
Como podemos ver na citação do próprio
documento oficial, é muito facil acontecer adocumento 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.

3. 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 desseUnificando.Vamos simplificar o nome desse
modelo para Merge.
2. Lock-Modify-Unlock ou Bloqueando-
Modificando-Liberando. Vamos simplificar o
nome desse modelo para Lock.

4. PERSONAGENS
Responsável pela validação.
Grupo de desenvolvedores
Desenvolvedor

5. MAU GERENCIAMENTO DOS ARQUIVOS EM
PRODUÇÃO
Não criada
referência a
versão.
Produção
(Build)
Repositório de desenvolvimento(Trunk)

6. REFERENCIANDO ARQUIVOS DE PRODUÇÃO
Produção
(Build)
Repositório de produção(Tag)

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

8. RESOLUÇÃO DE CONFLITOS
Repositório de
Edit Conflicts
Resolução do conflito
Repositório de
desenvolvimento(Trunk)
Merge

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

10. BRANCHING (P2)
/projeto_dev2
/projeto_dev1
Merge
/projeto_devn
Versões que carregam necessidade de testes e validações devem ser
encaminhadas para branches.
Repositório de
ramificações(branches)

11. LOCK
Repositório de desenvolvimento(Trunk)
Lock(bloqueia)
Repositório de desenvolvimento(Trunk)
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.

12. QUEBRANDO O VERSIONAMENTO
Utilizar pastas do
projeto não versionadas
quebra o versionamento.
Se você precisa
ramificar (colocar em
uma pasta avulsa) a suauma 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.

13. QUEBRANDO O VERSIONAMENTO
Repositório de desenvolvimento(Trunk)
Quebra de versionamento

14. QUEBRANDO O VERSIONAMENTO (P2)
Repositório de desenvolvimento(Trunk)
Quebra de versionamento

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

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

17. UTILIZANDO O BRANCHES.
Repositório de desenvolvimento(Trunk) Repositório de ramificações(branches)
/projeto_devn
/projeto_dev1
Publica
MERGE

18. 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 update
tentará 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.

19. 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.rREVANTfilename.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.

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

21. FIM
Autor: Cláudio da Costa Apolônio
Técnologo em Processamento de Dados – Fatec-BS(Rubens Lara)
Pós-Graduando em Gerencimento de Projetos – Senac-SP (Santos)