gerar o conflito$svn commit -m "Alterando o arquivo trunk/teste.txt para dar conflito"Enviando trunk/teste.txtTransmitindo dados do arquivo .Commit da revisao 8. $svn updateNa revisao 8.5.5 Vejam os logs com a armadilha pronta :-)$svn log------------------------------------------------------------------------r8 | marcello | 2008-07-16 23:44:19 -0300 (Qua, 16 Jul 2008) | 1 line Alterando o arquivo trunk/teste.txt para dar conflito------------------------------------------------------------------------r7 | marcello | 2008-07-16 23:43:31 -0300 (Qua, 16 Jul 2008) | 1 line Alterando o arquivo branches/marcello/trunk/teste.txt para dar conflito------------------------------------------------------------------------5.6 Fazer um merge para simular o conflito$svn merge https://svn.cercomp.ufg.br/svn/teste/trunk@7 https://svn.cercomp.ufg.br/svn/teste/branches/1.0@8 /trunkC trunk/teste.txt5.7 Fazendo o commit$svn commit -m "merge braches/1.0 into trunk"svn: Commit falhou (detalhes a seguir):svn: Abortando commit: '.../trunk/teste.txt' continua em conflito5.8 Resolvendo um conflito$cd trunk $lsteste.txt teste.txt.mesclagem-direita.r8 teste.txt.mesclagem-esquerda.r7 teste.txt.trabalho $cat teste.txtlinha 1<<<<<<>>>>>> .mesclagem-direita.r85.9 Arrumando a bagunca segundo a nossa vontade, ficando:linha 1linha 2 //mexendo na linha 2 do branches/1.0/teste.txt $svn resolved teste.txtEstado de conflito resolvido para 'teste.txt' $svn commit -m "merge braches/1.0 into trunk"Enviando trunk/teste.txtTransmitindo dados do arquivo .Commit da revisao 9. $svn updaterevisao 9.6. Ciclo de processo de trabalho no subversion Minha Traducao svn-book.pdfRevisao 116, Subtitulo: Release Branches Nocoes previas:trunk = tronco, corpobranches = ramos, bracostags = folhas, marcas, liberacoes pontuaisrelease = liberacao Pagina 95 Muitos software tem tipicamente os ciclo de vida: codificacao, teste, liberacao, volta a codificacao. Ha dois problemas neste processo. Primeiro, desenvolvedores precisam continuar escrevendo novas funcionalidades enquanto o equipe de qualidade testa a suposta versao estavel do software. O trabalho nao pode parar enquanto o software esta sendo testando. Segundo, a equipe em muitos casos sempre suportam outras versoes do software; se um bug e descoberto na ultima versao, e provavel que exista em versoes liberadas, e os usuarios vao querer que voce corrija sem ter que esperar por novas liberacoes em grande escala. Isto pode ajudar no controle de versao. O processo tipico tem esta aparencia: Desenvolvedores commitam todo o trabalho para dentro do trunk. Dia apos dia mudacas sao acrescentadas ao /trunk: novas funcionalidades correcao de defeitos e outros. O tronco e copiado para a liberacao ramo. Entao a equipe acredita que o software ja esta pronto para liberacao (dizemos, uma liberacao 1.0), entao /trunk podera ser copiado para /branches/1.0 Equipes continuam trabalhando em paralelo. Uma equipe inicia um rigoroso teste em uma liberacao ramo, enquanto uma outra equipe trabalha para uma versao em grande escala (dizemos, versao 2.0) sobre o /trunk. Se defeitos sao descobertos em outros locais, correcoes sao transportadas de volta e sao criadas quando necessario. Neste ponto, no entanto o processo para. A branch e congelada para testes finais antes de uma liberacao. O ramo e marcado e liberado. Entao o teste esta completo, /branches/1.0 e copiado para /tags/1.0.0 como referencia da imagem. A tag e empacotada e liberada para os usuarios. O ramo e mantida por todo o tempo. Enquanto o trabalho continua sobre o /trunk para a versao 2.0, correcoes continuam a ser transportadas do /trunk para branches/1.0. Quanto acumula-se correcoes, o gerente pode decidir fazer a liberacao 1.0.1: /branches/1.0 e copiada para /tags/1.0.1, e a folha e empacotada e distribuida. Toda repeticao desse processo amadurece: entao o trabalho 2.0 esta completo, uma nova