Devo adicionar arquivos .vcxproj.filter ao controle de origem?

169

Ao avaliar o Visual Studio 2010 Beta 2, vejo que no diretório convertida, meus vcproj arquivos tornou-se vcxproj arquivos. Também existem arquivos vcxproj.filter ao lado de cada projeto que parecem conter uma descrição da estrutura da pasta (\ Arquivos de Origem, \ Arquivos de Cabeçalho, etc.).

Você acha que esses arquivos de filtro devem ser mantidos por usuário ou devem ser compartilhados por todo o grupo de desenvolvedores e verificados no SCC?

Meu pensamento atual é fazer o check-in, mas me pergunto se há alguma razão para não fazer isso, ou talvez boas razões pelas quais eu definitivamente deveria fazer check-in.

O benefício óbvio é que as estruturas de pastas corresponderão se eu estiver olhando para a máquina de outra pessoa, mas talvez eles desejem reorganizar as coisas logicamente?

— jschroedl
fonte

59

As versões anteriores do Visual Studio (pelo menos as versões 6.0 e 2008) armazenam essas informações em seu próprio arquivo de projeto (arquivos .dsp e .vcproj respectivamente), o que obviamente é bom adicionar ao SCC.

Não consigo pensar em nenhum motivo para não incluir esses arquivos .filter no SCC

— jrbjazz
fonte

Estou contigo. Eu verifiquei. Obrigado!

— jschroedl

111

Intencionalmente, puxamos o filtro. informações do arquivo fora do .vcproj quando traduzimos para o formato .vcxproj MSBuild. Um dos motivos é exatamente o que você apontou, que os filtros são puramente uma visão lógica e que diferentes membros da equipe podem querer diferentes visões. A outra é que, às vezes, a compilação é configurada para verificar o registro de data e hora do arquivo do projeto e acionar uma reconstrução se ela tiver sido alterada - porque isso pode significar que existem arquivos de origem diferentes para compilar ou configurações diferentes, etc. lembre-se de que realmente enviamos com a compilação sendo acionada dessa maneira, mas a idéia era que não queríamos desencadear uma reconstrução simplesmente porque os filtros foram alterados, pois não afetam a compilação.

— dan moseley
fonte

3

para reconstruções automáticas, você cria se algum arquivo foi alterado (por exemplo, fonte); agora, nada mudou, exceto que temos outro arquivo para gerenciar.

— Gbjbaanb

3

em outras palavras, você gerencia os dois arquivos como se fossem um. Acho que ninguém mais os tratará separadamente. Sua idéia boa, mas um pouco de pensamento sobre as práticas do mundo real teria ido um longo caminho (como colocar o tempo de execução em WinSxS)

— gbjbaanb

9

Eu os trato separadamente. Para mim, quanto menos porcaria que precisar ser preservada como parte do estado do projeto, melhor, então acho que é uma boa decisão.

— rwallace

6

Podemos desativar completamente esses filtros se não quisermos usar nenhuma árvore abstrata / lógica, mas apenas ver o sistema de arquivos simples?

— Johan Boulé

4

@JohanBoule: Eu concordo totalmente! Eles deveriam ter descartado os filtros no IDE. Já existe uma estrutura em árvore lógica e é chamada "sistema de arquivos". Atualmente, existe muita duplicação - cada arquivo deve ser adicionado ao sistema de arquivos, ao script de construção (vcxproj), filtros (vcxproj.filters), controle de origem e talvez em outro lugar. Ele viola o princípio seco. Felizmente , parece que os arquivos de filtro são opcionais . Você pode simplesmente excluí-los e usar o botão "Mostrar todos os arquivos" no IDE. Pena que não é o padrão.

— Yakov Galka

5

Acabei de descobrir que, se você usar o Git, poderá marcar os arquivos .filter a serem tratados como uma união para mesclagem, para simplificá-lo. Basta adicionar a linha:

*.vcxproj.filters merge=union

ao seu arquivo .gitattributes.

Consulte Usando .gitattributes para evitar conflitos de mesclagem para obter mais detalhes.

— parsley72
fonte

O link mencionado não diz que esse arquivo .filters deve ter "union" mencionado no arquivo gitattributes.

— precisa saber é o seguinte

2

Mas diz o que merge=unionfaz - nada mais foi prometido. Com esse conhecimento e uma ideia muito ampla de como os arquivos * .filter se parecem, é fácil ver por que merge=unioné uma boa idéia para esses arquivos.

— Peter Schneider

1

Não devem ser adicionados no caso de você usar CMake(ou ferramentas de compilação semelhantes) para gerar arquivos como *.sln, *.vcxproj, *.vcxproj.filtersetc., porque estes arquivos podem conter caminho completo para a pasta do projeto e outros apenas pastas específicas do seu computador .

— V. Panchenko
fonte