resolução de conflitos svn binários

Question

I usar o SVN para um projeto im trabalhando com um par de outros desenvolvedores. Svn fino trabalha para controle de origem no entanto, são todas as formas recebendo conflitos quando nos comprometemos as DLLs.

Quando eu faço para resolver o conflito (que exclui os meus DLLs como o programa diff não posso lidar com arquivos binários), então tem que reconstruir a cometer. Como você está destinado a resolver conflitos como este?

Editar:

As DLLs estão em uma pasta SVN separado, como o projeto é um mod do jogo e não programadores precisam ter acesso às últimas compilações.

Answer 1

Como mencionado em outras respostas aqui: você não deve versão suas DLLs gerados em primeiro lugar. Mas se você realmente Have para a versão deles, então você pode resolver um conflito sem usar uma ferramenta de comparação que remove seus arquivos DLL:

Para cada arquivo em conflito, o Subversion mantém três arquivos extras não-versionados em sua cópia de trabalho:

filename.mine

Este é o seu arquivo como o que existia em sua cópia de trabalho antes de você atualizou sua cópia-que o trabalho é, sem marcações de conflito. Este arquivo tem apenas as suas últimas alterações nele. (Se o Subversion considerar que o arquivo a ser mesclável, o arquivo .mine não é criado, uma vez que seria idêntico ao arquivo de trabalho.)

filename.rOLDREV

Este é o arquivo que foi a revisão BASE antes de você atualizar sua cópia de trabalho. Ou seja, o arquivo que você check-out antes de fazer suas últimas edições.

filename.rNEWREV

Este é o arquivo que seu cliente Subversion acabou de receber do servidor quando você atualizou sua cópia de trabalho. Este arquivo corresponde à revisão HEAD do repositório.

Aqui OLDREV é o número de revisão do arquivo no diretório .svn, e NEWREV é o número de revisão da cabeça repositório.

Agora, para resolver tal conflito, remova os arquivos adicionais que você não quer:

• Se você quer manter sua própria dll, excluir os arquivos filename.rOLDREV, filename.rNEWREV
• Se você quiser manter o dll a partir do repositório, exclua os arquivos filename.rOLDREV e filename.mine, em seguida, copiar filename.rNEWREV para filename

Depois disso, execute

svn resolved filename

para dizer ao Subversion que você resolveu o conflito si mesmo.

Answer 2

Se for uma DLL que você está construindo (em vez de um externo você não tem fonte para), em seguida, a fonte deve estar no controle de origem, e não o binário.

Se você não quiser incluí-lo nesse repositório particular, então você pode incluí-lo como um svn:. Externa

Answer 3

Geralmente, você não iria armazenar suas próprias DLLs compilados no controle de origem em tudo. Você tem uma razão específica que você precisa fazer isso?

Criei meus ambientes de desenvolvimento para que qualquer pessoa pode construir qualquer um dos meus componentes do projeto de forma independente de qualquer outra pessoa. Desta forma, a única coisa que está em meu sistema de controle de origem é o meu source código. Isto tem uma série de benefícios:

• Evita conflitos de arquivos binários ao tentar check-in DLLs ou EXEs
• O volume de dados rastreados pelo sistema de controle de origem é muito menor, tornando mais rápido
• Quando os desenvolvedores sempre construir suas próprias DLLs, então eles podem estar razoavelmente certo que o código fonte têm corresponde ao arquivo compilado. Se você estiver usando algo que alguém construiu, então você nunca pode ter certeza.

Como mencionado nos comentários, pode ser perfeitamente razoável para armazenar DLLs de terceiros em seu sistema de controle de origem, especialmente se você realmente não tem a fonte para eles. Eu também trabalhou em projetos onde nós armazenados arquivos de distribuição (.tar.gz etc) para várias bibliotecas de código aberto no controle de origem, em seguida, teve todo um sistema de Makefiles que construiu os bibliotecas como parte de uma compilação-tudo -alvo.

Answer 4

Para arquivos binários, na maioria das vezes, você quer aceitar uma ou outra versão do mesmo. Por exemplo, se o arquivo em questão é uma ferramenta executável, em seguida, normalmente uma versão pode ser mais recente do que o outro, e isso pode ser o que você deseja usar.

Para aceitar a versão que está no ramo que estão se fundindo a partir, use:

svn resolve --accept=theirs-full path/to/filename

Para aceitar a versão que estava anteriormente no ramo atual, use:

svn resolve --accept=mine-full path/to/filename

Às vezes, SVN irá se recusar a usar theirs-full com um aviso:

svn: warning: W195024: Inapplicable conflict resolution option given for conflicted path

porque SVN é um pedaço de merda quando se trata de fusão. Nesse caso, você tem que copiar arquivos manualmente como na resposta aceita https://stackoverflow.com/a/410767/2279059, em vez de usar opções de linha de comando que são destinados para o que você está tentando fazer. Se você conhece os dois arquivos são idênticos (mas SVN ainda está marcando-os como conflito por razões já indicadas), você também pode usar

svn resolve --accept=working path/to/filename

Enquanto isso, no caso de arquivos idênticos, é efetivamente o mesmo que todos os outros comandos, SVN recusará não covarde para executá-lo. Isso faz sentido? Não, isso não acontece. Lidar com ele.

Answer 5

É razoável também têm binários em controle de versão:

• Ele evita o incômodo de reconstrução para as pessoas que só usam o binário.

• O binário é pregado para baixo quando você soltar.

Para fazer este trabalho às necessidades binários para sempre correspondem às fontes. Então se você tem fontes incorporadas você precisa reconstruir o binário a partir deles, escolhendo um dos binários do versões não vai fazer mescladas.

Answer 6

Certifique-se de suas DLLs tem o conjunto de propriedades svn:mime-type para application/octet-stream ou algum outro tipo não-texto.

svn propget *.dll
svn propset svn:mime-type application/octet-stream *.dll

Você ainda vai ter que realmente resolve conflitos quando eles ocorrem.

E verificar o Arquivo Tipo de conteúdo capítulo da documentação.

Answer 7

Então, se você tem as .dlls * em uma pasta separada é mais fácil fazer o máximo seguintes:

1. Diretamente antes de construir sua atualização mudança seu * .dll pasta melhor também atualizar suas fontes, se você confia, que seus colegas cometemos somente código fonte compilável. (Em caso de conflito (o que seria sua culpa nesse ponto, como você mudou alguma coisa antes de você atualizado para última revisão))
2. Faça a sua construção.
3. Diretamente comprometer o resultado.

Como alternativa:

não constroem para o caminho no diretório, compilação para fora em algum lugar, até que você esteja estão felizes com o que é o resultado.

Em seguida, faça o seguinte:

1. Atualize sua cópia de trabalho das DLLs pasta (se houver qualquer conflito a sua culpa sua e resolver o conflito por "manter deles")
2. Copie seus .dlls que trabalham para a cópia de trabalho
3. Informe seus colegas que você vai cometer uma nova revisão (você pode deixar este passo)
4. Entregue o seu trabalho, se houver qualquer conflito deve ser culpa deles.

Você tem duas possibilidades agora:

5a. Você é uma pessoa muito detestável e resolver o problema, mantendo o meu.

5b. Você trabalha como você deve trabalhar ... Leia o arquivo de log e descobrir quem também se comprometeu durante o curto período de tempo que você precisava para copiar o seu trabalho para a pasta e pressionou cometer. Fale com esse colega. Acordar entre si o curso de ação.