Em algum momento você poderá se deparar com um conflito quando for atualizar/unificar seus arquivos desde o repositório ou quando você for modificar sua cópia local para uma URL diferente. Existem dois tipos de conflitos:
Um conflito de arquivo ocorre se dois (ou mais) desenvolvedores modificam as mesmas linhas de um arquivo.
Um conflito de estrutura ocorre quando um desenvolvedor move/renomeia/elimina um arquivo ou uma pasta que outro desenvolvedor tenha também movido/renomeado/eliminado ou ainda apenas modificado.
A file conflict occurs when two or more developers have changed the same few lines of a file. As Subversion knows nothing of your project, it leaves resolving the conflicts to the developers. The conflicting area in a text file is marked like this:
<<<<<<< filename
your changes
=======
code merged from repository
>>>>>>> revision
Also, for every conflicted file Subversion places three additional files in your directory:
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.
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.
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.
Podes lançar uma ferramenta externa de integração/ editor de conflitos com → ou poderás utilizar um qualquer editor de texto para resolver o conflito manualmente. Deverás decidir como é que irá ficar o código, efectua as alterações necessárias e guarda o ficheiro. Usando uma ferramenta de integração como o TortoiseMerge ou uma das outras ferramentas populares, é na generalidade a opção mais fácil já que apresentam na generalidade os ficheiros envolvidos numa painel de 3 vistas e não têm de se preocupar com os marcadores de conflitos. Se usares um editor de ficheiro terás então de pesquisar por linhas começadas pela string <<<<<<<.
Em seguida execute o comando → e submeta suas modificações no repositório. Por favor, note que o comando Resolver não resolve o conflito. Ele apenas remove os arquivos filename.ext.mine e filename.ext.r*, para permitir que você submeta suas modificações.
Se tiver conflitos com arquivos binários, Subversion não irá incluir esses arquivos (propriamente dito). A cópia local permanece inalterada (exatamente como a modificação mais recente) e você terá arquivos filename.ext.r*. Se desejar descartar as modificações e manter a versão do repositório, apenas utilize o comando Reverter. Se desejar manter sua versão e sobreescrever o repositório, utilize o comando Resolvido e submeta sua versão.
Você pode utilizar o comando Resolvido para múltiplos arquivos se clicar com o botão direito do mouse na pasta que contém os arquivos e selecionar → Isto fará aparecer uma caixa de diálogo de todos os arquivos em conflito naquela pasta e então poderá selecionar quais deverão ser assinalados como resolvido.
Um conflito de propriedade acontece quando dois ou mais desenvolvedores mudaram a mesma propriedade. Assim como para o conteúdo, resolver conflitos pode ser feito apenas pelos desenvolvedores.
Se uma das alterações deve sobreescrever outra então escolha a opção Resolver usando a propriedade local ou a opção Resolver usando a propriedade remota. Se as alterações devem ser combinadas então selecione Editar a propriedade manualmente, altere o valor da propridade como ela deve ser e marque como resolvido.
Um conflito de estrutura ocorre quando um desenvolvedor move/renomeia/elimina um arquivo ou uma pasta que outro desenvolvedor tenha também movido/renomeado/eliminado ou ainda apenas modificado. Existem diversas situações que podem resultar num conflito de estrutura e cada situação exigirá uma ação diferente para a solução do conflito.
Quando um arquivo é eliminado localmente na Subversão, o arquivo também é eliminado do sistema local de arquivos ou seja, mesmo que seja parte do conflito de estrutura isso não comprova ser uma sobreposição de conflito e você não poderá clicar nele com o botão direito do mouse, para resolver o conflito. Utilize a caixa de diálogo Verificar por Modificações ao invés de acessar a opção Editar conflitos.
TortoiseSVN pode auxiliar para encontrar o lugar correto para aplicar modificações mas poderão existir tarefas adicionais e requeridas para a solução de conflitos. Lembre-se que após uma atualização, a BASE de trabalho sempre conterá a revisão de cada item tal como era no repositório no momento da atualização. Se você reverter uma modificação após uma atualização, o repositório não retornará ao estado original, tal como era antes das modificações que você iniciou localmente.
Desenvolvedor A modifica Foo.c e o submete para o repositório.
Desenvolvedor B simultaneamente moveu Foo.c para Bar.c em sua cópia local ou simplesmente eliminou Foo.c ou a pasta que o continha.
Uma atualização da cópia de trabalho do desenvolvedor B resulta num conflito de estrutura:
Foo.c foi eliminado da cópia de trabalho mas está marcado com um conflito de estrutura.
Se o conflito resulta por ter renomeado ao invés de ter eliminado então Bar.c estará marcado como adicionado mas não irá conter as modificações do desenvolvedor A.
Desenvolvedor B agora deverá escolher se mantém ou não as modificações do desenvolvedor A. No caso de um arquivo ter sido renomeado, ele poderá submeter as modificações de Foo.c para o arquivo renomeado Bar.c. No caso de simples arquivo ou pasta deletada, ele poderá escolher entre manter o item com as modificações do desenvolvedor A e descartar o arquivo eliminado. Ou então, poderá marcar o conflito como resolvido sem tomar qualquer atitude e efeticamente irá descartar as modificações do desenvolvedor A.
The conflict edit dialog offers to merge changes if it can find the original file of the renamed Bar.c. If there are multiple files that are possible move sources, then a button for each of these files is shown which allow you to chose the correct file.
Desenvolvedor A move Foo.c para Bar.c e submete para o repositório.
Desenvolvedor B modifica Foo.c na sua cópia de trabalho.
Ou no caso de um diretório movido ...
Desenvolvedor A move a pasta que o continha de FooFolder para BarFolder e submete para o repositório.
Desenvolvedor B modifica Foo.c na sua cópia de trabalho.
Uma atualização na cópia de trabalho do desenvolvedor B resulta num conflito de estrutura. Para um simples conflito de arquivo:
Bar.c é adicionado na cópia de trabalho como um arquivo normal.
Foo.c é assinalado como adicionado (com histórico) e indica um conflito de estrutura.
Para um conflito de pasta:
BarFolder é adicionada para a cópia de trabalho como uma pasta normal.
FooFolder é assinalada como adicionada (com histórico) e indica um conflito de estrutura.
Foo.c é assinalado como modificado.
Desenvolvedor B agora terá que decidir o que fazer com a reorganização do desenvolvedor A e submeter suas modificações para o arquivo correspondente na nova estrutura ou simplesmente reverter as modificações do desenvolvedor A e manter o arquivo local.
To merge her local changes with the reshuffle, Developer B must first find out to what filename the conflicted file Foo.c was renamed/moved in the repository. This can be done by using the log dialog. Then use the button which shows the correct source file to resolve the conflict.
If Developer B decides that A's changes were wrong then she must choose the Mark as resolved button in the conflict editor dialog. This marks the conflicted file/folder as resolved, but Developer A's changes need to be removed by hand. Again the log dialog helps to track down what was moved.
Desenvolvedor A move Foo.c para Bar.c e submete para o repositório.
Desenvolvedor B move o arquivo Foo.c para Bix.c.
Uma atualização da cópia de trabalho do desenvolvedor B resulta num conflito de estrutura:
Bix.c é marcado como adicionado com histórico.
Bar.c é adicionado na cópia local com status "normal".
Foo.c é marcado como eliminado e possui um conflito de estrutura.
Para resolver este conflito, Desenvolvedor B terá que descobrir para qual nome o arquivo em conflito Foo.c foi renomeado/movido no repositório. Isto pode ser feito usando a caixa de diálogo do log.
Em seguida, o Desenvolvedor B terá que decidir se o novo nome do arquivo Foo.c será mantido - se aquele dado pelo Desenvolvedor A ou se aquele renomeado por ele mesmo.
Depois que o Desenvolvedor B tenha manualmente solucionado o conflito, o conflito de estrutura deve ser marcado como "resolvido", usando o botão apropriado na caixa de diálogo do Editor de Conflitos.
Desenvolvedor A trabalhando no trunk, modifica o arquivo Foo.c e submete o arquivo para o repositório
Desenvolvedor B trabalhando com o branch, move e renomeia o arquivo Foo.c para Bar.c e submete a alteração para o repositório
A atualização do Desenvolvedor A no trunk e a do Desenvolvedor B no branch, resulta num conflito de estrutura:
Bar.c já está na cópia de trabalho com status "norma"'.
Foo.c está assinalado como "desaparecido" e com um conflito de estrutura.
Para solucionar este conflito, o Desenvolvedor B terá que marcar esse arquivo como "resolvido" na caixa de diálogo do Editor de Conflitos - o qual irá removê-lo da lista de conflitos. O Desenvolvedor B terá então que decidir se deve copiar o arquivo Foo.c "desaparecido" do repositório para a cópia de trabalho ou então se deve atualizar as modificações do Desenvolvedor A no arquivo Foo.c para o arquivo renomeado como Bar.c ou então se deve ignorar as modificações marcando o conflito como resolvido e fazer nada mais.
Note que se você copiar o arquivo "desaparecido" do repositório e então marcá-lo como resolvido, esse arquivo copiado será removido novamente. Você deve primeiro, resolver o conflito.
Desenvolvedor A trabalhando em trunk move Foo.c para Bar.c e o submete para o repositório.
Desenvolvedor B trabalhando no branch modifica o arquivo Foo.c e o submete para o repositório.
Desenvolvedor A trabalhando no trunk move a pasta FooFolder para BarFolder e submete a alteração para o repositório.
Desenvolvedor B trabalhando no branch modifica o arquivo Foo.c em sua cópia de trabalho.
A atualização do Desenvolvedor A no trunk e a do Desenvolvedor B no branch, resulta num conflito de estrutura:
Bar.c é marcado como adicionado.
Foo.c é marcado como modificado com um conflito de estrutura.
Desenvolvedor B agora terá que decidir o que fazer com a reorganização do desenvolvedor A e submeter suas modificações para o arquivo correspondente na nova estrutura ou simplesmente reverter as modificações do desenvolvedor A e manter o arquivo local.
To merge her local changes with the reshuffle, Developer B must first find out to what filename the conflicted file Foo.c was renamed/moved in the repository. This can be done by using the log dialog for the merge source. The conflict editor only shows the log for the working copy as it does not know which path was used in the merge, so you will have to find that yourself. The changes must then be merged by hand as there is currently no way to automate or even simplify this process. Once the changes have been ported across, the conflicted path is redundant and can be deleted.
If Developer B decides that A's changes were wrong then she must choose the Mark as resolved button in the conflict editor dialog. This marks the conflicted file/folder as resolved, but Developer A's changes need to be removed by hand. Again the log dialog for the merge source helps to track down what was moved.
Desenvolvedor A trabalhando em trunk move Foo.c para Bar.c e o submete para o repositório.
Desenvolvedor B trabalhando em um ramo, move e renomeia o arquivo Foo.c para Bix.c e submete a alteração para o repositório.
A atualização do Desenvolvedor A no trunk e a do Desenvolvedor B no branch, resulta num conflito de estrutura:
Bix.c é marcado com Status de normal (não modificado).
Bar.c é marcado como adicionado com histórico.
Foo.c é marcado como inexistente e como tendo um conflito de estrutura.
To resolve this conflict, Developer B has to find out to what filename the conflicted file Foo.c was renamed/moved in the repository. This can be done by using the log dialog for the merge source.
Em seguida, o Desenvolvedor B terá que decidir se o novo nome do arquivo Foo.c será mantido - se aquele dado pelo Desenvolvedor A ou se aquele renomeado por ele mesmo.
Depois que o Desenvolvedor B tenha manualmente solucionado o conflito, o conflito de estrutura deve ser marcado como "resolvido", usando o botão apropriado na caixa de diálogo do Editor de Conflitos.
Há outros casos em que são identificados como conflitos de estrutura simplesmente porque o conflito envolve um diretório ao invés de um arquivo. Por exemplo, se você adicionar um diretório com o mesmo nome no tronco e no ramo e então tentar combiná-los você terá um conflito de estrutura.