SVN como resolver novos conflitos de árvore quando o arquivo é adicionado em dois ramos

Ao mesclar alguns ramos (usando SVN 1.6.1), onde um arquivo foi adicionado em ambos os ramos (e depois trabalhado nesses ramos separados), estou recebendo um dos novos conflitos de árvore:

      C foo.txt
  >   local obstruction, incoming add upon merge

Preciso das alterações de ambos os ramos, mas o conflito da árvore não me dá os arquivos .working, .merge-left e .merge-right usuais - o que é compreensível devido à natureza do conflito. Existem alguns desses conflitos, e aqueles em que a exclusão do mesmo arquivo ocorreu em cada ramificação, mas eles são simples de resolver.

Como posso resolver esse problema? O livro SVN redbean (para 1.6) não cobre esta situação.

Como foi mencionado em uma versão mais antiga (2009) do documento de design "Tree Conflict" :

Conflito XFAIL da fusão do arquivo adicionado sobre a versão

Este teste faz uma fusão que traz uma adição de arquivo sem histórico em um arquivo com versão existente .
Isso deve ser um conflito de árvore no arquivo da local obstruction, incoming add upon mergevariedade ' '. Expectativas corrigidas em r35341.

(A propósito, isso também é chamado de "gêmeos do mal" no ClearCase):
um arquivo é criado duas vezes (aqui "adicionado" duas vezes) em duas ramificações diferentes, criando duas histórias diferentes para dois elementos diferentes, mas com o mesmo nome.

A solução teórica é mesclar manualmente esses arquivos (com uma ferramenta de diff externa) no branch de destino ' B2'.

Se você ainda estiver trabalhando na ramificação de origem, o cenário ideal seria remover esse arquivo da ramificação de origem B1, mesclar novamente de B2para B1para tornar esse arquivo visível em B1(você trabalhará então no mesmo elemento).
Se uma mesclagem não for possível porque as mesclagens ocorrem apenas de B1a B2, uma mesclagem manual será necessária para cada B1->B2mesclagem.

Encontrei um post sugerindo uma solução para isso . Está prestes a ser executado:

svn resolve --accept working <YourPath>

que reivindicará os arquivos da versão local como OK.
Você pode executá-lo para um único arquivo ou catálogos de projetos inteiros.

E se as mudanças recebidas forem as que você deseja? Não consigo executar svn resolve --accept theirs-full

svn resolve --accept base

Eu apenas consegui me firmar completamente tentando seguir o conselho do user619330 acima. A situação era: (1): Eu adicionei alguns arquivos enquanto trabalhava em meu branch inicial, branch1; (2) Eu criei um novo branch, branch2 para desenvolvimento posterior, ramificando-o do tronco e, em seguida, mesclando minhas alterações do branch1 (3) Um colega de trabalho copiou meus mods do branch1 para seu próprio branch, adicionou outros mods, e, em seguida, mesclado de volta ao tronco; (4) Agora eu queria mesclar as alterações mais recentes do tronco em meu branch de trabalho atual, branch2. Isso ocorre com o svn 1.6.17.

A fusão teve conflitos de árvore com os novos arquivos, e eu queria a nova versão do tronco onde eles diferiam, então a partir de uma cópia limpa do branch2, fiz um svn delete dos arquivos conflitantes, efetuei essas alterações do branch2 (criando assim um arquivo temporário versão do branch2 sem os arquivos em questão), e então fiz a minha mesclagem do tronco. Fiz isso porque queria que o histórico correspondesse à versão do tronco para que eu não tivesse mais problemas posteriormente ao tentar mesclar de volta ao tronco. A fusão correu bem, obtive a versão do tronco dos arquivos, svn st mostra tudo ok, e então eu achei mais conflitos de árvore enquanto tento enviar as alterações, entre a exclusão que fiz anteriormente e a adição da fusão. Resolvi um svn dos conflitos em favor da minha cópia de trabalho (que agora tinha a versão do tronco dos arquivos) e fiz o commit.

Bem não. Uma atualização de outra cópia do branch2 resultou na versão antiga dos arquivos (mesclagem pré-tronco). Portanto, agora tenho duas cópias de trabalho diferentes do branch2, supostamente atualizado para a mesma versão, com duas versões diferentes dos arquivos, e ambos insistindo que estão totalmente atualizados! O check-out de uma cópia limpa do branch2 resultou na versão antiga (pré-tronco) dos arquivos. Eu os atualizo manualmente para a versão do tronco e confirmo as alterações, volto para a minha primeira cópia de trabalho (da qual eu tinha enviado as alterações do tronco originalmente), tento atualizá-lo e agora obtenho um erro de checksum nos arquivos em questão. Explodir o diretório em questão, obter uma nova versão via atualização e, finalmente, tenho o que deve ser uma boa versão do branch2 com as alterações do tronco. Eu espero. Aviso ao desenvolvedor.