Sugestões para manter arquivos de projeto Visual vcproj Estúdio no controle de versão

StackOverflow https://stackoverflow.com/questions/611925

Pergunta

Microsoft Visual Studio usa XML para salvar seus arquivos de projeto .vcproj. Então comparar ficheiros de projeto XML deve ser facilmente.

Infelizmente, se você alterar qualquer uma das propriedades do arquivo do projeto, Visual Studio insiste em baralhar aleatoriamente os nós XML do arquivo de projeto! Isso faz com que diffing textuais e fusão de arquivo de projeto muda basicamente impossível. Alterar uma configuração compilador pode fazer a minha ferramenta de comparação visual acho que mudei 50% das linhas no arquivo! Eu até tentei algumas ferramentas diff XML, mas apenas mostrar uma visão mais estruturada da mesma confusão.

Alguém tem alguma sugestão para manutenção de arquivos .vcproj no controle de origem? Ou uma maneira de convencer o Visual Studio para não reorganizar os nós XML no arquivo .vcproj?

(eu também têm investigado usando ferramentas como CMake para gerar arquivos .vcproj de um arquivo de texto mais amigável-diff, mas CMake tem seus próprios problemas.)

Foi útil?

Solução

Este parece vir-se de vez em quando.

Talvez seja um maduro problema para um plug-in ou outra ferramenta de normalização.

Seria uma grande equipa-business, até MS decide corrigi-lo. Então você está fora de sorte - a menos, claro, que eles oferecem para comprar seu IP

.

Qualquer um quer começar um projeto open source, ou produto comercial? Eu sou jogo.

Eu poderia ter ir em uma ferramenta de normalização stand-alone, e depois ver se eu posso transformá-lo em um plugin.

Outras dicas

Estamos vendo isso aqui no trabalho agora, com arquivos de projeto, onde as configurações são reordenadas em vários computadores povos, e é muito frustrante ...

* Nota: Nós todos uso VS 2008 Pro, não Equipe

No começo parece que eles são reordenadas aleatoriamente, mas há de fato um padrão e não é aleatório em tudo.

Para um grupo as configurações são ordenados por Platform, em seguida, por Config:

  • Debug | Win32
  • Debug | x64
  • Release | Win32
  • Release | x64
  • Debug DX11 | Win32
  • Debug DX11 | x64
  • Release DX11 | Win32
  • Release DX11 | x64
  • ...

Para o outro grupo as configurações são ordenados por Config, em seguida, pela Plataforma:

  • Debug | Win32
  • Release | Win32
  • Debug DX11 | Win32
  • Release DX11 | Win32
  • Debug | x64
  • Release | x64
  • Debug DX11 | x64
  • Release DX11 | x64
  • ...

Olhando através da história forçosamente, isso é consistente com vários projectos apresentados pelos mesmos conjuntos de pessoas, e há cerca de uma divisão de 50/50, por isso não está acontecendo só para uma pessoa.

Este é o mesmo problema que você está vendo tudo? Se assim for, espero que este padrão ajuda a encontrar uma solução que não envolve um macro / step diff adicional ...

Tem que ser um lugar configuração, ou um efeito colateral de clicar em alguma coisa, uma vez que é 100% reproduzível por cada uma destas máquinas. Mesmo se é algo bobo como opção que você escolher para o seu layout inicial ambiente (VC ++, VB, Desenvolvimento geral, ect ...)

Eu uso WinMerge como meu diff-ferramenta e eu habilitado a detecção bloco movido. Ele não chega a resolver o problema, mas torna visualizando as diferenças um pouco mais suportável.

Qual versão do Visual Studio que você está vendo isso em?

Eu faço um monte de trabalho com .vcproj arquivos (mantemos versões dos arquivos de projeto para nossas bibliotecas em várias versões do Visual Studio, e eu estou sempre diffing e fundindo as coisas), mas eu nunca vi esse comportamento.

A minha equipa a Adobe tem visto a mesma coisa em vs2008. Apenas um debug / release básico, win32 / win64 projeto dá-lhe 4 configurações e baralhar aleatório. Várias pessoas têm tentado descobrir quando e por que DevStudio reordena, mas o pensamento atual é a chave de ordenação é um hash de palavras-chave - daí semi-aleatória. Nós desistimos e em revisões de código apenas resumir as mudanças "reais".

Eu acho que eu encontrei a razão para esta shuffle. Pelo menos no VS2008.

Se você instalar os compiladores x64, VS irá encomendar projetos como: 

Debug|Win32
Debug|x64
Release|Win32
Release|x64

Se você não fizer isso vai encomendá-los como: 

Debug|Win32
Release|Win32
Debug|x64
Release|x64

Certifique-se assim todos os seus pares têm o mesmo conjunto compilador instalado, por isso não vai baralhar.

Testado e este comportamento parece ser reproduzível.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top