Por que estou recebendo conflitos de árvore no Subversion?

Eu tinha um ramo de recursos do meu tronco e estava mesclando alterações do meu tronco no meu ramo periodicamente e tudo estava funcionando bem. Hoje fui mesclar o ramo novamente no tronco e qualquer um dos arquivos que foram adicionados ao meu tronco após a criação do meu ramo foram sinalizados como um "conflito de árvore". Existe uma maneira de evitar isso no futuro?

Eu não acho que estes estão sendo devidamente sinalizados.

Encontrei a solução lendo o link fornecido por Gary (e sugiro que siga este caminho).

Resumindo para resolver o conflito de árvore que confirma seu diretório de trabalho com o cliente SVN 1.6.x, você pode usar:

svn resolve --accept working -R .

onde .está o diretório em conflito.

ATENÇÃO : "Confirmando seu diretório de trabalho" significa que sua estrutura de sandbox será a que você está comprometendo; portanto, se, por exemplo, você excluiu algum arquivo da sandbox, eles também serão excluídos do repositório. Isso se aplica apenas ao diretório em conflito.

Dessa forma, sugerimos que o SVN resolva o conflito ( --resolve), aceitando a cópia de trabalho dentro da sua sandbox ( --accept working), recursivamente ( -R), começando no diretório atual (. ).

No TortoiseSVN, selecionar "Resolvido" com o botão direito do mouse resolve o problema.

O Subversion 1.6 adicionou Tree Conflicts para cobrir conflitos no nível do diretório. Um bom exemplo seria quando você excluir um arquivo localmente e, em seguida, uma atualização tentará trazer uma alteração de texto para esse arquivo. Outra é quando você tem uma subversão Renomear de um arquivo que está editando, pois é uma ação Adicionar / Excluir.

O Blog de Subversion da CollabNet tem um ótimo artigo sobre Tree Conflicts .

Na minha experiência, o SVN cria um conflito de árvore SEMPRE que eu excluo uma pasta. Parece não haver razão.

Eu sou o único trabalhando no meu código -> excluir um diretório -> confirmar -> conflito!

Mal posso esperar para mudar para o Git .

Eu devo esclarecer - eu uso o Subclipse . Provavelmente esse é o problema! Mais uma vez, mal posso esperar para mudar ...

Não sei se isso está acontecendo com você, mas às vezes escolho o diretório errado para mesclar e recebo esse erro, mesmo que todos os arquivos pareçam completamente bem.

Exemplo:

Mesclar / svn / Project / branches / some-branch / Fontes para / svn / Project / trunk ---> Conflito em árvore

Mesclar / svn / Project / branches / some-branch para / svn / Project / trunk ---> OK

Isso pode ser um erro estúpido, mas nem sempre é óbvio, porque você acha que é algo mais complicado.

O que está acontecendo aqui é o seguinte: Você cria um novo arquivo no seu tronco e o mescla no seu ramo. Na consolidação de mesclagem, esse arquivo também será criado em sua ramificação.

Quando você mescla sua ramificação novamente no tronco, o SVN tenta fazer o mesmo novamente: ele vê que um arquivo foi criado em sua ramificação e tenta criá-lo em seu tronco na confirmação de mesclagem, mas ela já existe! Isso cria um conflito de árvore.

A maneira de evitar isso é fazer uma mesclagem especial, uma reintegração . Você pode conseguir isso com o --reintegrateswitch.

Você pode ler sobre isso na documentação: http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate

Ao mesclar sua ramificação de volta ao tronco, no entanto, a matemática subjacente é bem diferente. Sua ramificação de recursos agora é uma mistura de alterações de tronco duplicadas e de ramificações privadas, portanto, não há um intervalo contíguo simples de revisões para copiar. Ao especificar a opção --reintegrate, você está pedindo ao Subversion que replique cuidadosamente apenas as alterações exclusivas de sua ramificação. (Na verdade, ele faz isso comparando a árvore de tronco mais recente com a árvore de ramificação mais recente: a diferença resultante é exatamente a alteração de sua ramificação!)

Após a reintegração de um ramo, é altamente recomendável removê-lo, caso contrário, você continuará recebendo conflitos de conflito sempre que se fundir na outra direção: do tronco para o seu ramo. (Exatamente pelo mesmo motivo descrito anteriormente.)

Também há uma maneira de contornar isso, mas nunca tentei. Você pode lê-lo neste post: Reintegração de ramificação do Subversion na v1.6

Isso pode ser causado pelo não uso de toda a mesma versão dos clientes.

Usar um cliente da versão 1.5 e um cliente da versão 1.6 no mesmo repositório pode criar esse tipo de problema. (Eu só fui mordido.)

Se você encontrar conflitos de árvore que não fazem sentido porque não editou / excluiu / chegou perto do arquivo, há também uma boa chance de que haja um erro no comando mesclar.

O que pode acontecer é que você já mesclou anteriormente várias alterações incluídas na mesclagem atual. Por exemplo, no porta-malas, alguém editou um arquivo e depois o renomeou. Se em sua primeira mesclagem você incluir a edição e, em uma segunda mesclagem, incluir a edição e a renomeação (essencialmente uma remoção), isso também causará um conflito de árvore. A razão para isso é que a edição mesclada anteriormente aparece como sua e, portanto, a remoção não será realizada automaticamente.

Isso pode ocorrer pelo menos nos repositórios 1.4, não tenho certeza se o rastreamento de fusões introduzido na 1.5 ajuda aqui.

Até hoje, há pelo menos três meses, encontrei regularmente centenas de conflitos de árvores ao tentar mesclar um ramo de volta ao tronco (usando o TortoiseSVN 1.11 ). Seja rebased ou não, entre. Eu uso o TortoiseSVN desde a v1, em 2004, e costumava reintegrar ramificações o tempo todo. Algo deve ter acontecido recentemente, suponho.

Hoje, eu fiz esse experimento simples e descobri o que estava criando esses conflitos malucos:

1. Eu peguei o porta-malas @ 393;
2. Modifiquei dezenas de arquivos aleatoriamente, além de criar novos;
3. Eu cometi. Agora @ 395 (um colega partiu aos 394 para fazer suas próprias coisas).
4. Depois tentei reintegrar o galho de volta ao tronco, apenas para teste; seguindo a recomendação do TortoiseSVN no assistente: "para mesclar todas as revisões (reintegrar), deixe essa caixa vazia". Para conseguir isso, cliquei com o botão direito do mouse na pasta do tronco e escolhi "TortoiseSVN> Mesclar, de / path / to / branch" e deixei o intervalo de rotação vazio , conforme recomendado na caixa de diálogo.

Discussão: (ver anexo)

todas as revisões ... de quê? Mal sabia eu que o cliente deveria estar se referindo a " todas as revisões do alvo! (Tronco)", pois, no processo de reintegração desse ramo, vi a menção "Mesclando revisões 1-HEAD"! AMD. Pobre diabo, você está morrendo aqui. Esse ramo nasceu @ 393, você não pode ler a certidão de nascimento, pelo amor de Deus?

Resolução:

1. Ao contrário do recomendado pelo wiz, especifique um intervalo que cubra TODAS as revisões da ... vida do ramo! portanto, 394-HEAD ;
2. Agora execute esse teste de mesclagem novamente e pegue um charuto. ( )

Moral: Não consigo entender por que eles ainda não corrigiram esse bug, porque é um, desculpe-me. Eu deveria reservar um tempo para relatar isso com eles.

Também me deparei com esse problema hoje, embora meu problema específico provavelmente não esteja relacionado ao seu. Depois de inspecionar a lista de arquivos, percebi o que havia feito - estava temporariamente usando um arquivo em um assembly de outro assembly. Fiz muitas alterações e não quis tornar órfã o histórico do SVN; portanto, na minha ramificação, havia movido o arquivo da pasta da outra montagem. Isso não é rastreado pelo SVN; portanto, parece que o arquivo foi excluído e depois adicionado novamente. Isso acaba causando um conflito de árvore.

Eu resolvi o problema movendo o arquivo de volta, cometendo, e , em seguida, fundir meu ramo. Depois mudei o arquivo novamente. :) Isso parecia fazer o truque.

Eu tive um problema parecido. A única coisa que realmente funcionou para mim foi excluir os subdiretórios em conflito com:

svn delete --force ./SUB_DIR_NAME

Em seguida, copie-os novamente de outro diretório raiz na cópia de trabalho que os possui:

svn copy ROOT_DIR_NAME/SUB_DIR_NAME

Então faça

svn cleanup

e

svn add *

Você pode receber avisos com o último, mas apenas ignorá-los e finalmente

svn ci .

Eu tive esse mesmo problema e o resolvi refazendo a mesclagem usando estas instruções . Basicamente, ele usa a "mesclagem de 2 URLs" do SVN para atualizartrunk para o estado atual de sua ramificação, sem se preocupar muito com o histórico e os conflitos em árvore. Me salvou de corrigir manualmente 114 conflitos de árvore.

Não tenho certeza se preserva a história tão bem quanto se gostaria, mas valeu a pena no meu caso.

Um cenário em que às vezes encontro:

Suponha que você tenha um tronco, a partir do qual você criou uma ramificação de liberação. Após algumas alterações no tronco (em particular, criando o diretório "some-dir"), você cria um ramo de recurso / correção, que também deseja mesclar posteriormente no ramo de lançamento (porque as alterações foram pequenas o suficiente e o recurso / reparo é importante para o lançamento) .

trunk -- ... -- create "some-dir" -- ...
     \                                  \-feature/fix branch
      \- release branch

Se você tentar mesclar a ramificação feature / fix diretamente na ramificação release, você obterá um conflito de árvore (mesmo que o diretório nem existisse na ramificação feature / fix):

svn status
!     C some-dir
      >   local missing or deleted or moved away, incoming file edit upon merge

Portanto, você precisa mesclar explicitamente as confirmações feitas no tronco antes de criar a ramificação feature / fix que criou o diretório "some-dir" antes de mesclar a ramificação feature / fix.

Costumo esquecer que, como isso não é necessário no git.