Como você administra .vcproj arquivos no controle de origem que são trocados por múltiplos desenvolvedores?

Question

Nós usamos Subversion como nosso sistema de controle de origem e armazenar os arquivos de projeto VisualStudio (vcproj) no sistema de controle de origem, como é normal, eu acho. Com Subversion não usamos qualquer forma de bloqueio de arquivos, por isso, se dois desenvolvedores estão trabalhando no mesmo projeto ao mesmo tempo e ambos os arquivos adicionar ao projeto, ou alterar as configurações, o segundo a cometer tem que mesclar as alterações.

Como você mesclar essas mudanças?

Os arquivos vcproj são apenas arquivos de texto assim que é possível editá-los à mão, mas eles não são muito passíveis de edição mão, especialmente por desenvolvedores júnior.

As maneiras que eu posso pensar são

• Obter a versão mais recente do SVN e adicionar novamente todas as alterações locais manualmente
• Editar o arquivo manualmente para resolver os conflitos de uma fusão automática
• implementar alguma forma de esquema de bloqueio para evitar alterações simultâneas
• Tenha um acordo entre os desenvolvedores para que eles não fazer alterações simultâneas

Atualmente estamos usando a primeira opção de re-adicionando todas as alterações manualmente, mas este é demorado e eu queria saber se existe uma maneira melhor.

Com arquivos de origem o recurso mala automático funciona na maioria das vezes e nós não temos muitos conflitos.

Answer 1

Descobri que a opção 2 (editar os arquivos à mão) geralmente funciona razoavelmente bem, enquanto você estiver usando uma boa ferramenta de diff (eu uso WinMerge ). O principal problema eu correr em é que Visual Studio, às vezes, reordenar o arquivo. Mas, se você tiver uma boa ferramenta de diff / merge, em seguida, ele deve ser capaz de diferenciar entre conteúdo alterado e conteúdo movido. Isso pode ajudar muito.

Answer 2

Você pode achar Projeto: fundir ou Ferramentas para arquivo SLN útil

Answer 3

Este é um problema difícil e acho que uma fraqueza na arquitetura Visual Studio. A forma que encontramos rodada era para não ter os arquivos de proj no controle de origem em tudo e ter um script de construção que lidou com as definições de configuração.

A alternativa era muito confuso e não poderia garantir consistente constrói ou ambientes entre os desenvolvedores. Isto levou a um grande número de problemas de integração a jusante e, eventualmente, deu o passo draconiana de remover os arquivos de projeto do controle de origem.

Os ambientes desenvolvedores ainda poderia ficar desalinhado, mas ele mostrou-se quando eles tentaram construir coisas em si.

Answer 4

Usando TFS aqui, mas eu não acho que isso faz a diferença.
Nós também não bloquear, e às vezes tem que lidar com a fusão arquivos de projeto. Eu nunca achei que fosse tão complexo ou um grande problema. Raramente nós sempre questões de experiência que não podem ser fundidos automaticamente eo processo de mesclagem manual é bastante trivial.

Há apenas uma ressalva a esta: Check-in, muitas vezes! Se você fazer grandes alterações na estrutura do projeto e não vê-los imediatamente essas mudanças podem começar compondo a complexidade das integrações posteriores. Se eu fizer uma mudança importante para a estrutura de um projeto, eu costumo dar a todos um heads-up. Vou pedir a todos para verificar em seu trabalho atual e, em seguida, cuidar da fusão mim.

Answer 5

Eu encontrei este recentemente: http://www.codeproject.com/KB/macros /vcproj_formatter.aspx Se você executar esta ferramenta em um arquivo vcproj e em uma versão modificada do mesmo, então você pode fundi-las facilmente com sua ferramenta favorita texto merge, e, além disso o resultado é um arquivo vcproj muito mais compacto.

Answer 6

Opções 1 e 2 não são mutuamente exclusivas - se o desenvolvedor é o nível júnior, deixá-los usar a opção 1 (re-obter o arquivo de projeto e re-fazer as mudanças) se isso é mais confortável para eles. Para os desenvolvedores mais experientes, a opção 2 (merge usando uma ferramenta de mesclagem) está perfeitamente bem.

Eu acho que esta é uma situação que atualmente tem nenhuma bala mágica -. Às vezes fusão é uma dor

Answer 7

Nós usamos uma ferramenta de comparação ( WinMerge ) às mudanças de mesclagem. Os arquivos de projeto são (em sua maior parte) XML realmente simples. A chave aqui, porém, é que nunca deve haver surpresas quando se fundem, porque a boa comunicação é parte do leito de rocha de controle de origem eficaz.

mudanças simultâneas para o projeto são perfeitamente bem, desde que as pessoas se comunicam.