Subversion Ferramentas Cliente

Transcrição

1 Revisão 0 Pág. 1/31 Histórico de Revisões Revisão Autor Data Histórico 0 Eric Lemes 05/06/2006 Criação do documento. 1 Cláudio Alves 27/11/2006 Inclusão dos tópicos: Conceitos básicos de controle de versão de software; Diff; Resolvendo Conflitos; e Branches e Merge. Índice 1. Objetivo Insumos necessários Conceitos básicos de controle de versão de software Working Copy Histórico de Alterações Instalação do TortoiseSVN Usando o TortoiseSVN Criação do diretório base Checkout Alterando arquivos Commit Update Diff Lock Adicionando Arquivos ou Diretórios Removendo Arquivos ou Diretórios Ignorando Arquivos ou Diretórios Relocate Alterando o servidor para onde a cópia local irá mandar as alterações Revert - Desprezando suas alterações Resolvendo Conflitos Merge Automático Merge Conflitante Branches e Merge Trabalhando com o seu Branch Instalação do NAnt Scripts de Build com NAnt Boas Práticas Manter o repositório compilável Dicas para Evitar Conflitos Considerações Finais Página 1 de 31

2 Revisão 0 Pág. 2/31 1. Objetivo O objetivo deste documento é descrever a instalação e principais formas de operação do cliente TortoiseSVN, para acessar repositórios do Subversion. O ambiente utilizado é o Windows XP. 2. Insumos necessários As versões homologadas dos instaladores necessários encontram-se em (endereço interno ou 3. Conceitos básicos de controle de versão de software Muitos problemas que ocorrem durante o desenvolvimento de software são causados por falta de controle sobre os arquivos do projeto. O processo de controle de versão evita alguns problemas, como: 1. Perder versões anteriores do código do projeto. 2. Problemas em manter diferentes versões do sistema ao mesmo tempo. 3. Perder alterações pelo motivo de alguém da equipe sobrescrever o código de outra pessoa por acidente. 4. Dificuldades em saber quais as alterações efetuadas em um programa, quando foram feitas e quem fez. Por isso, as equipes de trabalho necessitam de um controle de versão, a fim de ajudá-los a manter o controle sobre as constantes alterações do projeto. Um Sistema de controle de versão deve rastrear e controlar todos os artefatos do projeto (código-fonte, documentação, arquivos de configuração, protótipos, dentre outros) e desse modo coordenar o trabalho paralelo de coordenadores, desenvolvedores, analistas e outros membros da equipe do projeto. Este tipo de Sistema é caracterizado por algumas funcionalidades em comum, como: 1. Manter e disponibilizar cada versão já produzida de cada item do repositório. 2. Possuir mecanismo de gerenciar diferentes versões do repositório ao mesmo tempo. O Subversion traz o conceito de branches que atende muito bem este item. Página 2 de 31

3 Revisão 0 Pág. 3/31 3. Ter uma política de sincronização das mudanças sem sobrepor o que foi feito por outros membros da equipe. 4. Fornecer um histórico de alterações de cada item do repositório. Por isso, devemos aplicar o Sistema de controle de versão em todo projeto de desenvolvimento de software. Todos os arquivos e diretórios que compõem um projeto ficam sob a responsabilidade do Sistema de controle de versão num local denominado de repositório. O Sistema de controle de versão registra todas as mudanças em arquivos e diretórios controlados no repositório. À medida que o projeto evolui, o repositório passa a guardar múltiplas versões dos arquivos que compõem o projeto. Essas múltiplas versões são organizadas em revisões. Uma revisão funciona como uma "foto" de todos os arquivos do projeto em um determinado momento do tempo. As "fotos" antigas são mantidas e podem ser recuperadas e analisadas a qualquer momento. Mesmo que não haja alteração em um arquivo entre uma revisão e outra, o número da revisão do arquivo acompanha o número da revisão global, de modo a manter sempre um grupo coeso e coerente de arquivos Working Copy Os desenvolvedores não trabalham diretamente nos arquivos do repositório. Cada desenvolvedor possui uma cópia de trabalho (Working Copy) que espelha os arquivos do repositório para trabalhar com liberdade enquanto termina suas tarefas, isolado dos outros desenvolvedores. Página 3 de 31

4 Revisão 0 Pág. 4/ Histórico de Alterações Como o repositório registra todas as alterações efetuadas, o sistema de controle de versão pode informar com facilidade quais as alterações que foram realizadas entre uma revisão e outra, quando isso ocorreu e quem fez as alterações. Essas informações permitem um controle maior sobre mudanças no projeto. 4. Instalação do TortoiseSVN Executar o instalador. Devido a uma restrição do Asp.net com diretórios que iniciam com., precisamos realizar uma configuração no Subversion para que ele crie seus diretórios de controle com _svn, invés de.svn. Para isso, devemos seguir os seguintes passos: clique com o botão direito em qualquer janela do Windows Explorer, em seguida TortoiseSVN Settings. Ligue a opção Use _svn instead of.svn directories. Esta opção encontra-se na Tab General. Clique em Apply. Reinicie a máquina. Página 4 de 31

5 Revisão 0 Pág. 5/31 5. Usando o TortoiseSVN 5.1. Criação do diretório base Assim como no Visual Source Safe criávamos o diretório C:\VSSBase para os projetos, precisamos de um diretório local para o Subversion. Utilizaremos o C:\SandBoxes Checkout A operação de Checkout para o SubVersion possui um conceito diferente da operação de Checkout do Visual Source Safe. No SubVersion o Checkout significa a primeira vez em que é criada uma Working Copy (cópia de trabalho, cópia local) do repositório. Para realizarmos um checkout no nosso repositório, clicamos com o botão direito no Windows Explorer em cima do diretório C:\SandBoxes, depois em SVN Checkout. A URL do repositório será fornecida pelo gestor do projeto. Geralmente ela tem a forma Observe atentamente a diferenciação de maiúscula/minúscula no nome do repositório. Deve ser extamente igual à fornecida. Em Checkout directory, mantenha como C:\SandBoxes\NomeDoRepositorio. Não necessariamente o diretório precisa ter o mesmo nome do repositório. Na opção revision, mantenha HEAD revision. Clique em Ok, o TortoiseSVN irá pedir a autenticação do servidor. Utilize a própria autenticação do Active Directory, com o seu nome de usuário prefixado pelo domínio (Ex.: architettura\usuario). É recomendável ligar o Save Authentication, para que ele não fique solicitando a autenticação toda hora. Se por alguma razão, desejar apagar as informações de autenticação, clique com o botão direito no Windows Explorer, depois TortoiseSVN, Settings e na tab General, clique em Clear Now à frente de Subversion authentication data. Após finalizar o checkout, você observará um ícone verde exibido sobre o diretório. Isso indica que desde o último checkout ou update não houveram alterações no repositório. Página 5 de 31

6 Revisão 0 Pág. 6/ Alterando arquivos Os arquivos baixados pelo TortoiseSVN no diretório local ficam alteráveis (no Visual Source Safe eles ficavam Read Only). Você pode alterar à vontade os arquivos dentro da sua Working Copy. Nenhuma alteração vai para o repositório enquanto essas alterações acontecem. Sempre que um arquivo é alterado, o TortoiseSVN visualmente indica em quais arquivos e diretórios recursivamente houveram alterações, com o ícone vermelho Commit A operação de commit é a mais importante do SVN. Ela consiste em enviar as alterações realizadas na sua Working Copy para o repositório no servidor. Toda e qualquer operação como alteração de arquivo, Add, Delete, Rename, Ignore não acontecem até que seja realizado um commit no repositório. Assim como as demais operações do TortoiseSVN, elas podem ser executadas no diretório ou no arquivo. Caso seja executada no diretório, todos os arquivos e subdiretórios farão parte da mesma operação. Quando é realizada a operação de commit, a seguinte tela é exibida: Página 6 de 31

7 Revisão 0 Pág. 7/31 Clicando-se em Recent messages pode-se obter mensagens anteriormente usadas em commits. Na caixa de texto maior, abaixo de recent messages, devem ser adicionados comentários sobre as alterações realizadas no repositório. Em changes made, são exibidos todos os arquivos que estão diferentes do repositório (inclusive arquivos não versionados, recentemente adicionados, excluídos, propriedades de diretórios modificadas, etc.). Clicando em OK, as alterações são enviadas para o servidor. Se entre o momento em que suas alterações foram realizadas outro usuário alterou algum dos arquivos e subiu as alterações para o repositório (commit), vc receberá a mensagem: Nesse caso, realize um update na sua working copy e na seqüência realize um novo commit. Página 7 de 31

8 Revisão 0 Pág. 8/ Update Diferentemente da operação de Get do Visual Source Safe, o Update do TortoiseSVN significa pegar as alterações mais atuais do repositório e atualizar a Working Copy. A grande diferença é que o TortoiseSVN não sobrescreve as suas alterações. Para se realizar o update, clica-se com o botão direito sobre o arquivo ou diretório, depois em SVN Update. Caso seja selecionado um diretório, a operação é realizada recursivamente em todos os subdiretórios e arquivos. Caso as alterações tenham sido feitas em arquivos diferentes, o TortoiseSVN automaticamente os atualiza. Ex.: Caso as alterações tenham sido feitas no mesmo arquivo alterado em sua Working Copy, o TortoiseSVN pode tomar duas ações: Merge: Quando ele detecta que os arquivos foram alterados em linhas diferentes. Ex.: Página 8 de 31

9 Revisão 0 Pág. 9/31 Conflito: Quando dois arquivos foram alterados exatamente no mesmo lugar. Essa é uma situação rara, porém pode acontecer na prática. Quando uma situação de conflito acontece, o TortoiseSVN exibe o arquivo em conflito com o ícone amarelo e automaticamente tira backups dos arquivos, com as extensões: teste.txt.mine: A versão da working copy, sem qualquer alteração teste.txt.r6: A versão da revisão 6, anterior ao update teste.txt.r7: A versão da revisão 7, revisão posterior ao update. No caso de conflito deve ser realizado um Diff manual do arquivo. Sempre que clica-se com o botão direto sobre o arquivo e posteriormente TortoiseSVN Diff, é realizado um diff do arquivo alterado local (lado direito do diff) e a última revisão do repositório (lado esquerdo do diff). Após a resolução do conflito, deve-se clicar sobre o arquivo com o botão direito depois TortoiseSVN Resolved. As cópias de backup são automaticamente limpadas, o arquivo fica com o ícone vermelho e as alterações somente serão efetivadas no repositório quando for realizado um commit. Página 9 de 31

10 5.6. Diff Revisão 0 Pág. 10/31 O comando DIFF do SubVersion tem por objetivo apresentar as diferenças entre revisões de um mesmo arquivo. Este processo é muito importante, pois temos que deixar o arquivo coeso com as alterações realizadas sobre o mesmo antes de submetê-lo (commit) ao repositório da solução. Este comando é parte importante para exercemos mais adiante o processo de merge. Podemos empregar o comando DIFF em três práticas distintas: Examinar alterações locais de um arquivo. Comparar a sua cópia de trabalho (working copy) com o repositório da solução. Comparação entre repositórios. Para examinarmos os exemplos seguintes, vamos utilizar o repositório chamado: diff. Neste existe apenas dois diretórios trunk e branches. Criaremos um arquivo chamado: Pessoa.cs no repositório diff/trunk. O mesmo está descrito abaixo: using System; public class Pessoa { public string Nome { get { return "Cláudio Alves Jr"; public int Idade { get { return 29; No próximo passo vamos adicionar e submeter o arquivo ao repositório. Para testarmos o diff entre arquivos locais vamos alterá-lo algumas vezes. Altere a string de retorno da propriedade Nome para Ana Paula Arósio. Execute o comando commit. Também altere o inteiro de retorno da propriedade Idade para 32. Execute o comando commit novamente. Podemos consultar no log do repositório as revisões efetuadas. Para isso, vamos chamar no diretório trunk do repositório diff à operação Show Log do TortoiseSVN. Página 10 de 31

11 Revisão 0 Pág. 11/31 A figura abaixo apresenta o resultado da operação show log. É apresentado o repositório na revisão 5. Também podemos conferir os comentários de cada commit realizado no repositório. Os colaboradores do projeto devem efetuar comentários de tal forma que quaisquer outros colaboradores possam compreender e, se necessário, prosseguir com o desenvolvimento do Sistema, além de possibilitar informações detalhadas para futuras manutenções. Com a operação de diff nós podemos conferir as diferenças do arquivo Pessoa.cs entre as revisões realizadas sobre o mesmo. Vamos chamar a operação Show Log do TortoiseSVN a partir do diretório trunk do repositório. Com a tela - Show Log aberta selecione as revisões que se deseja comparar e clique com o botão direito do mouse sobre algum dos itens selecionados. A partir daí você chama a opção Compare Revisions. A figura a seguir apresenta a operação descrita acima. Página 11 de 31

12 Revisão 0 Pág. 12/31 Agora o TortoiseSVN vai apresentar uma lista com os arquivos modificados entre as revisões 3 e 5. Dê um duplo clique sobre o arquivo Pessoa.cs e veja o resultado abaixo: As linhas distintas são destacadas pelo aplicativo. Página 12 de 31

13 Revisão 0 Pág. 13/31 Essa funcionalidade nos dá um leque enorme de variedades sobre o quê desejamos obter, como Diferenças em repositórios distintos; examinar diferenças entre arquivos locais; e examinar diferenças entre o arquivo local e o arquivo num determinado repositório (como branches e tags) Lock A operação de lock consiste em evitar que qualquer outro usuário realize commits até que sua alteração seja finalizada. Esse recurso é importante para arquivos binários, porém, em arquivos fonte deve ser evitada (as situações de merge salvam a maioria dos casos). Assim como as demais operações do TortoiseSVN, elas podem ser realizadas para o diretório e para o arquivo. No caso do diretório, o lock se aplicará também a todos os subdiretórios e arquivos. No momento do Commit, existe a opção Keep locks. caso ela esteja ligada, o lock será mantido mesmo após a realização do commit. O default é desligada (remove os locks no momento do commit) Adicionando Arquivos ou Diretórios Sempre que um novo arquivo é jogado na Working Copy, por default ele fica como Nãoversionado. Para fazer o TortoiseSVN reconhecer um arquivo, deve se clicar com o botão direito nele depois em TortoiseSVN Add. Quando o Add é realizado, o arquivo ainda não foi efetivamente para o repositório. Somente no próximo commit ele será enviado Removendo Arquivos ou Diretórios Sempre que um arquivo é excluído da Working Copy, ele não foi removido do repositório. No próximo update, ele será novamente baixado do repositório. Se desejar excluir efetivamente um arquivo ou diretório, deve-se clicar com o botão direito sobre ele, depois em TortoiseSVN depois em Delete. Mesmo o arquivo sumindo da working copy, ele não foi efetivamente removido do repositório. Somente no próximo commit ele será efetivamente removido desta revisão. Consultando em revisões anteriores, o arquivo ainda existirá e poderá ser recuperado Ignorando Arquivos ou Diretórios Alguns arquivos criados pela IDE as vezes servem apenas para controlar informações na máquina local, e não devem ser versionados. Nessa categoria temos:.appdata,.suo,.pdb, entre outros. Binários que podem ser gerados através de fontes também não são bem-vindos (O ideal é utilizar um script de build que permita regerar esses binários à partir do fonte a qualquer momento). Para que o TortoiseSVN não fique mais notificando alterações nesses arquivos ou diretórios, basta clicar com o botão direito sobre ele TortoiseSVN Add to ignore list. Página 13 de 31

14 Revisão 0 Pág. 14/31 Para a alteração surtir efeito, deve ocorrer um commit no diretório (a informação de ignore é uma propriedade do diretório) Relocate Alterando o servidor para onde a cópia local irá mandar as alterações. Em alguns casos, pode ser necessário modificar o servidor para onde sua Working Copy aponta. Isso acontece principalmente, quando muda-se fisicamente de lugar e continua-se acessando por IP Externo. Imagine que dentro da rede local, o repositório esteja em e que na rede externa esteja em Para alterar o endereço na rede, clica-se com o botão direito sobre o diretório principal de repositório, na seqüência Relocate Revert - Desprezando suas alterações Caso você tenha realizado alterações em sua working copy e deseje desprezá-las, podemos usar o comando Revert, clicando com o botão direito, TortoiseSVN Revert. Como praticamente todos os comandos do TortoiseSVN ele pode ser aplicado somente num arquivo ou num diretório. No caso do diretório, ele irá recursivamente se aplicando em subdiretórios e arquivos. 6. Resolvendo Conflitos Em síntese o processo de merge trabalha gerando uma lista com as diferenças entre os pontos distintos em um repositório, e aplica estas diferenças para a sua working copy (cópia de trabalho). Este processo é muito utilizado quando você trabalha com vários branches. Basicamente, este recurso elimina a necessidade de recortar e colar alterações entre versões diferentes de repositórios. Os branches são usados para manter linhas de desenvolvimento separadas, e em algum estágio você pode querer mesclar (merge) as alterações de um branch específico com a versão de trunk (linha principal de desenvolvimento), ou vice-versa. A questão de conflitos entre arquivos é um processo normal para quem trabalha com o paradigma The Copy Modify Merge Solution. As figuras a seguir apresentam este paradigma: Página 14 de 31

15 Revisão 0 Pág. 15/31 Página 15 de 31

16 Revisão 0 Pág. 16/31 No SubVersion também temos o recurso de LOCK. Mas é desaconselhável o uso desta operação. A política "Lock Modify - UnLock" é restritiva e frequentemente atrapalha o trabalho dos usuários. O travamento pode causar alguns problemas administrativos e forçar a uma serialização desnecessária. A solução "The Copy Modify Merge Solution" parece um pouco caótica a princípio, mas funciona bem na prática. Conflitos (sobreposições de alterações nos mesmos trechos de um arquivo) são raros e são causados basicamente pela falta de comunicação entre desenvolvedores. Na grande maioria dos casos, as alterações não se sobrepõem e são mescladas automaticamente pelo sistema de controle de versão. A partir deste ponto vamos apresentar os dois tipos de Merge - Merge Automático e Merge Conflitante. Antes, vamos criar um ambiente de teste na estação de trabalho local. Primeiramente, vamos criar os diretórios em C:\SandBoxes, chamados de Saturno e Urano. Vamos considerar para efeito de teste que estes diretórios são dois desenvolvedores concorrentes do repositório diff, criado anteriormente neste documento. O próximo passo consiste em obter o trunk do repositório diff para os diretórios Saturno\diff-trunk e Urano\diff-trunk. Assim construímos um cenário para efetuar os testes. Página 16 de 31

17 Revisão 0 Pág. 17/ Merge Automático Chamamos de Merge Automático quando numa situação de conflito o próprio SubVersion consegue resolver o problema e deixa o arquivo coeso para submetê-lo ao repositório. Vamos criar um cenário de conflito. Utilizando o usuário Saturno em c:\sandboxes\saturno\diff-trunk\pessoa.cs altere o valor de retorno na propriedade Nome para Fernanda Lima. Por enquanto, não efetue o commit desta alteração. Agora, utilizando o usuário Urano em c:\sandboxes\urano\diff-trunk\pessoa.cs altere o valor de retorno da propriedade Idade para 26. Vamos submeter (commit) apenas esta última alteração do usuário Urano para o nosso repositório. A figura a seguir apresenta o resultado do commit realizado com sucesso. Vamos voltar ao diretório do usuário Saturno e submeter (commit) o arquivo c:\sandboxes\saturno\diff-trunk\pessoa.cs. A figura abaixo apresenta a mensagem de erro, informando que ocorreu um conflito no arquivo ao enviá-lo ao repositório. Página 17 de 31

18 Revisão 0 Pág. 18/31 Diante desta situação de conflito devemos efetuar a operação UPDATE do arquivo em c:\sandboxes\saturno\diff-trunk\pessoa.cs. Para isso selecione o arquivo de conflito e chame através do TortoiseSVN a operação SVN UPDATE. Para este processo de update podemos esperar dois resultados possíveis: O SubVersion consegue resolver o conflito e efetua um merge automático sobre o arquivo deixando-o coeso para submetê-lo ao repositório; Ou o SubVersion encontra uma situação de conflito e deixa para o usuário do repositório exercer as devidas alterações no arquivo, e a partir daí submetê-lo ao repositório. No exemplo realizado anteriormente os usuários Saturno e Urano trabalharam em pontos distintos do arquivo Pessoa.cs. Por isso, o SubVersion conseguiu realizar o processo de merge automático. Veja o resultado na figura abaixo: Página 18 de 31

19 Revisão 0 Pág. 19/31 Vimos que o SubVersion exerceu a ação Merged sobre o arquivo Pessoa.cs. Agora veremos como ficou o arquivo depois de efetuada a operação de update. using System; public class Pessoa { public string Nome { get { return "Fernanda Lima"; public int Idade { get { return 26; Perceba que o valor de retorno da propriedade Idade foi alterado para 26, como o usuário Urano havia submetido ao repositório. Já o valor de retorno da propriedade Nome ficou como estava. Ou seja, o processo de merge automático alterou (mesclando) apenas a parte submetida pelas revisões posteriores do arquivo que o usuário Saturno possui na sua cópia de trabalho (working copy). Agora devemos submeter (commit) o nosso arquivo ao repositório. A figura a seguir apresenta o cenário que tivemos neste tópico: Página 19 de 31

20 Revisão 0 Pág. 20/31 Página 20 de 31

21 Revisão 0 Pág. 21/ Merge Conflitante O merge conflitante ocorre quando o SubVersion não consegue resolver sozinho o processo de merge dos arquivos em conflito. Porém alguns arquivos são criados para auxiliá-lo na correção destes arquivos antes de submetê-los ao repositório. Vamos exemplificar esta operação. Mas para isso vamos efetuar o processo de update dos seguintes diretórios c:\sandboxes\saturno\diff-trunk e c:\sandboxes\urano\diff-trunk. Com a versão atualizada vamos prosseguir com o nosso exemplo. Utilizando o arquivo c:\sandboxes\saturno\diff-trunk\pessoa.cs vamos editar o valor de retorno da propriedade Idade para 27. Por enquanto não vamos submeter (commit) o arquivo ao repositório. Agora, utilizando o arquivo c:\sandboxes\urano\diff-trunk\pessoa.cs vamos editar o valor de retorno da propriedade Idade para 28. Vamos submeter (commit) apenas este arquivo para o nosso repositório. Vimos que o mesmo foi submetido com sucesso. Agora chegou a vez de submeter o arquivo do usuário Saturno. Não fica difícil de imaginar o quê vai ocorrer quando submetermos o arquivo ao repositório. Criou-se um novo conflito, como apresentado na figura a seguir: De frente com a situação de conflito, nós devemos realizar a operação SVN Update sobre o arquivo. Realizando este processo podemos conferir o resultado apresentado na figura a seguir: Página 21 de 31

22 Revisão 0 Pág. 22/31 O SubVersion não conseguiu resolver o problema de conflito. Porém foram criados alguns arquivos para nos auxiliar na correção do arquivo Pessoa.cs a fim de deixá-lo pronto para o commit. É importante saber o que significa cada um destes arquivos criados pelo SubVersion. Vamos a eles: Pessoa.cs.r7 cópia do arquivo Pessoa.cs na revisão 7. Por isso o arquivo finaliza com a extensão r7. O arquivo que estou editando na minha cópia de trabalho (working copy) encontra-se nesta revisão. Pessoa.cs.r8 cópia do arquivo na revisão 8. Esta revisão é a mais recente do nosso repositório. Pessoa.cs.mine é o arquivo local com o estado das alterações efetuadas sobre o mesmo. Vamos chamar o comando diff do TortoiseSVN sobre o arquivo Pessoa.cs. Página 22 de 31

23 Revisão 0 Pág. 23/31 Na figura abaixo podemos conferir o resultado na operação diff. Analisando os arquivos o usuário Saturno resolveu deixar o valor de retorno da propriedade Idade em 27. Este resultado é definido unicamente pelo usuário do repositório. NOTA Lembre-se de retirar as linhas comentadas e caracteres inseridos pelo SubVersion. Estes comentários servem para indicar os pontos de conflito entre os arquivos. Depois de corrigir o arquivo devemos chamar a operação Resolved do TortoiseSVN. Página 23 de 31

24 Revisão 0 Pág. 24/31 A operação Resolved vez com que os arquivos criados pelo UPDATE fossem excluídos. O nosso arquivo encontra-se pronto para submetê-lo ao repositório. 7. Branches e Merge Muitos projetos precisam de variações específicas. Um caso típico é para customizações feitas para atender determinados clientes que precisam de adaptações particulares. Outro caso comum é a criação de um ramo para experimentações no projeto, sem comprometer a linha principal de desenvolvimento. O sistema de controle de versão oferece funcionalidades que facilitam a coordenação de diferentes versões de desenvolvimento em um mesmo projeto. Definimos branches como linhas de desenvolvimento independentes com um histórico de revisões comuns para o repositório. O processo de criação de branches é bem simples. Nada mais é do que uma cópia de arquivos e diretórios de um local para outro. A figura a seguir apresenta os branches de desenvolvimento. Página 24 de 31

25 Revisão 0 Pág. 25/31 O SubVersion contém funcionalidades que ajudam a manter branches paralelos para seus arquivos e diretórios. Com isso conseguimos de forma simples duplicar as alterações de um branch para outro, e entre um branch e um trunk, fazendo com que um erro não seja propagado para outras versões do produto. Vamos exemplificar este tema utilizando o repositório diff criado neste documento. Devemos criar o seguinte diretório em nova estação de trabalho c:\sandboxes\diff-trunk. Realize o checkout do repositório diff. A figura abaixo apresenta o organograma do repositório diff. Com o branches 1.0 criado no repositório diff, passaremos a realizar o processo de checkout deste repositório em c:\sandboxes\diff-branches. O ciclo de desenvolvimento do projeto (novos processos) tem continuidade no trunk que é a linha principal de desenvolvimento. A manutenção do projeto vai ocorrer nos branches do repositório. No nosso caso, no branches/1.0. Sendo assim, todas as correções efetuadas nos branches devem ser replicadas para o trunk, evitando que os erros sejam novamente introduzidos em futuras versões do produto. Para isso, vamos fazer uso do merge entre os branches e o trunk. Merge Alterações Branches/1.0 trunk Página 25 de 31

26 Revisão 0 Pág. 26/ Trabalhando com o seu Branch Agora que temos o branch e fizemos o checkout do mesmo, vamos realizar alterações no seu repositório. Podemos abrir o arquivo c:\sandboxes\diff-branches\1.0\pessoa.cs e alterar a string de retorno da propriedade Nome para Fernanda Ávila Lima. Faça o commit do arquivo. Veja como deve ficar o arquivo do branches/1.0: using System; public class Pessoa { public string Nome { get { return "Fernanda Ávila Lima"; public int Idade { get { return 27; Enquanto isso, o trunk também passa por mudanças. Um novo método chamado Identificacao foi desenvolvido. O código abaixo apresenta o resultado final das alterações no arquivo Pessoa.cs do trunk. using System; public class Pessoa { public string Nome{ get { return "Fernanda Lima"; public int Idade { get { return 27; public string Identificacao() { return "Eu, " + Nome + " tenho " + Idade.ToString() + " anos."; Página 26 de 31

27 Revisão 0 Pág. 27/31 Utilizando o TortoiseSVN acompanhamos o histórico das revisões. Clique com o botão direito do mouse sobre o diretório diff-trunk e chame a operação Revision Graph. A figura a seguir apresenta o resultado: Chegou o momento de atualizarmos as mudanças realizadas no branches/1.0 para o trunk que é a linha principal de desenvolvimento do repositório. Vamos selecionar o diretório c:\sandboxes\diff-trunk pois é sobre o trunk que as alterações serão realizadas. Com o diretório selecionado devemos chamar a operação merge do TortoiseSVN. Nesta tela temos alguns parâmetros para preencher. É válido recordar que o branches/1.0 foi criado na revisão 10, como vimos na figura acima que apresenta o histórico das revisões. A última alteração no branches/1.0 foi feita na revisão 11. Portanto queremos as mudanças ocorridas entre as revisões 10 e 11. A figura a seguir apresenta a tela de merge com os devidos valores preenchidos. Página 27 de 31

28 Revisão 0 Pág. 28/31 O item 1 é a URL do repositório branches/1.0 onde queremos processar as diferenças entre as revisões dos arquivos. Os itens 2 e 3 são os valores das revisões inicial e final respectivamente. No item 4 deixamos a opção selecionada. Pois queremos comparar apenas as revisões do mesmo repositório. No item 5 vimos aonde o merge deve ser aplicado. O item 6 apresenta a URL correspondente ao repositório do item 5. Com a tela configurada temos quatro opções de operação. Vamos vê-las: Unified diff: gera um arquivo apresentando os pontos diferentes entre os arquivos modificados. Diff: apresenta uma lista com os arquivos que houveram mudanças. Podemos ver detalhes das alterações de cada arquivo. Para isso dê um clique com o botão direito do mouse sobre o arquivo e selecione a opção compare revisions. Dry run: simula a operação de merge. Merge: Aplica a operação de merge nos arquivos modificados entre as revisões. Usando a opção Diff vimos às partes distintas do arquivo Pessoa.cs. Página 28 de 31

29 Revisão 0 Pág. 29/31 Aplicando o merge no repositório temos o seguinte resultado no arquivo Pessoa.cs. using System; public class Pessoa { public string Nome{ get{ return "Fernanda Ávila Lima"; public int Idade{ get{ return 27; public string Identificacao(){ return "Eu, " + Nome + " tenho " + Idade.ToString() + " anos."; Veja que o merge alterou apenas o valor de retorno da propriedade Nome. O resto do arquivo ficou como o desenvolvido no trunk. Diante disso já podemos submeter (commit) o repositório. Página 29 de 31

30 Revisão 0 Pág. 30/31 8. Instalação do NAnt Descompacte o pacote.zip dentro do seu diretório Program Files. Adicione no PATH da máquina a pasta Bin do Nant. Clique com o botão direito em My Computer, depois Properties. Na aba Advanced, clique em Environment Variables No listbox System Variables, localize o PATH. Edite o PATH e adicione no final dela o caminho: C:\Program Files\Nant-X.X.X\Bin 9. Scripts de Build com NAnt Algumas aplicações já possuem dentro do repositório um diretório Build (geralmente abaixo do /trunk). Geralmente esse diretório conterá arquivos.bat que executam o nant apontando para um respectivo arquivo.build. Os arquivos de build devem ser criados dependendo de cada aplicação. Cada uma tem sua seqüência de compilação e dependências. A referência do NAnt possui todos os comandos possíveis para se criar os próprios scripts. 10. Boas Práticas Manter o repositório compilável No Visual Source Safe, até pela integração com a IDE, tínhamos a facilidade de diretamente do Visual Studio clicar com o botão direito no arquivo e dar um Check In. O principal problema dessa prática é sempre estar subindo alterações que mantém o repositório não-compilável. Isso prejudica os demais companheiros de equipe, caso durante o tempo da alteração toda ser conclúida ele precise atualizar o repositório. Com o SubVersion a intenção é fazer menos commits e commits mais completos, de forma a manter todo o repositório compilável. Assim, o fluxo para se trabalhar no dia-a-dia fica assim: Antes de começar a realizar uma implementação, dê um update em todo o repositório. Isso minimiza a possibilidade de ocorrerem merges e conflitos indesejados. Realize toda a alteração, teste tudo antes de fazer o commit. Garanta que o repositório está compilável antes de realizar o commit, executando o script de build da aplicação (se sua aplicação não tiver um script de build completo, pode ser uma boa chance de aprender a criar um). Página 30 de 31

31 Revisão 0 Pág. 31/31 Comente a alteração do commit. Se for uma nova funcionalidade explique de forma suscinta o que ela faz. Se for uma correção, informe o número do issue, ficha ou algo que ajude a rastrear a solução do problema e até uma breve descrição do que foi feito para resolvê-lo. Esse comentário será útil para gerar o changelog das versões e ainda, através do notificador comunicar aos demais membros da equipe o que está sendo feita (é uma forma de trocar experiência sem interromper o trabalho no dia-a-dia) Dicas para Evitar Conflitos Antes de realizar uma correção, assegure-se que nenhum outro membro da equipe está fazendo a mesma correção. Isso acontece com mais freqüência do que parece. É uma forma praticamente certa de ocorrer um conflito. Evite mais de uma pessoa mexendo no design de uma mesma tela. Merges de arquivos resx não constumam ser simples. Mantenha sua working copy sempre atualizada. 11. Considerações Finais Controle de Versão resolve diversos problemas básicos de desenvolvimento tais como uso de diferentes versões de código, sincronização do trabalho paralelo de desenvolvedores no mesmo projeto, recuperação de versões anteriores e registro do histórico de alterações. Controle de versão de software é uma prática de engenharia de software comprovadamente eficaz. Por isso, faz parte das exigências para melhorias do processo de desenvolvimento de certificações tais como CMMI e SPICE. O Subversion como uma excelente alternativa e que vem sendo utilizada por cada vez mais projetos em substituição do CVS. Página 31 de 31