Dois-je ajouter des fichiers .vcxproj.filter au contrôle de code source?

169

Lors de l'évaluation de Visual Studio 2010 Beta 2, je constate que dans le répertoire converti, mes fichiers vcproj sont devenus des fichiers vcxproj . Il existe également des fichiers vcxproj.filter à côté de chaque projet qui semblent contenir une description de la structure des dossiers (\ Source Files, \ Header Files, etc.).

Pensez-vous que ces fichiers de filtre devraient être conservés par utilisateur ou devraient-ils être partagés dans tout le groupe de développement et archivés dans SCC?

Ma pensée actuelle est de les enregistrer, mais je me demande s'il y a des raisons de ne pas le faire, ou peut-être de bonnes raisons pour lesquelles je devrais définitivement les enregistrer.

L'avantage évident est que les structures des dossiers correspondent si je regarde la machine de quelqu'un d'autre, mais peut-être qu'ils aimeraient réorganiser les choses de manière logique?

— jschroedl
source

59

Les versions précédentes de Visual Studio (au moins les versions 6.0 et 2008) stockent ces informations dans leur propre fichier de projet (fichiers .dsp et .vcproj respectivement), qu'il est bien entendu utile d'ajouter à SCC.

Je ne vois aucune raison de ne pas inclure ces fichiers .filter dans SCC

— jrbjazz
source

Je suis d'accord. Je l'ai vérifié. Merci!

— jschroedl

111

Nous avons intentionnellement retiré le .filter. informations de fichier hors du .vcproj lorsque nous avons traduit au format .vcxproj MSBuild. L'une des raisons est exactement ce que vous avez souligné, à savoir que les filtres sont purement une vue logique et que différents membres de l'équipe peuvent souhaiter des vues différentes. L'autre est que parfois la construction est configurée pour vérifier l'horodatage du fichier de projet et déclencher une reconstruction s'il a changé - car cela peut signifier qu'il y a différents fichiers source à construire, ou des paramètres différents, etc. rappelez-vous si nous avons réellement livré avec la construction le déclenchement de cette façon, mais l'idée était que nous ne voulions pas déclencher une reconstruction simplement parce que les filtres ont changé, car ils n'affectent pas la construction.

— dan moseley
source

3

pour les reconstructions automatiques, vous construisez si un fichier a changé (par exemple la source), donc maintenant rien n'a changé sauf que nous avons encore un autre fichier à gérer.

— gbjbaanb

3

Nous avons fini par les enregistrer et nous avons été satisfaits de cet arrangement jusqu'à présent. Il s'avère plus agréable pour nous de travailler avec d'autres développeurs s'ils ont la même structure de filtre.

— jschroedl

9

Je les traite séparément. En ce qui me concerne, moins il y a de merde à préserver dans le cadre de l'état du projet, mieux c'est, donc je pense que c'est une bonne décision.

— rwallace

6

Pouvons-nous désactiver complètement ces filtres si nous ne voulons pas utiliser d'arbre abstrait / logique mais simplement voir celui du système de fichiers?

— Johan Boulé

4

@JohanBoule: Je suis totalement d'accord! Ils devraient juste avoir mis au rebut les filtres dans l'EDI. Il existe déjà une arborescence logique et on l'appelle "système de fichiers". Actuellement, il y a beaucoup de duplication - chaque fichier doit être ajouté au système de fichiers, au script de construction (vcxproj), aux filtres (vcxproj.filters), au contrôle de source et peut-être ailleurs. Cela viole le principe DRY. Heureusement, il semble que les fichiers de filtre soient facultatifs . Vous pouvez simplement les supprimer et utiliser le bouton "Afficher tous les fichiers" dans l'EDI. Dommage que ce ne soit pas la valeur par défaut.

— Yakov Galka

5

Je viens de découvrir que si vous utilisez Git, vous pouvez marquer les fichiers .filter à traiter comme une union pour la fusion pour le rendre plus simple. Ajoutez simplement la ligne:

*.vcxproj.filters merge=union

dans votre fichier .gitattributes.

Voir Utilisation de .gitattributes pour éviter les conflits de fusion pour plus de détails.

— persil72
source

Le lien mentionné ne dit pas que ce fichier .filters doit avoir "union" mentionné dans le fichier gitattributes.

— ollydbg23

2

Mais il dit ce que merge=unionfait - rien d'autre n'a été promis. Avec ces connaissances et une idée très large à quoi ressemblent les fichiers * .filter, il est facile de comprendre pourquoi merge=unionest une bonne idée pour ces fichiers.

— Peter Schneider

1

Il ne doit pas être ajouté dans le cas où vous utilisez CMake(ou de construire des outils similaires) pour générer des fichiers comme *.sln, *.vcxproj, *.vcxproj.filtersetc., parce que ces fichiers peuvent contenir le chemin complet à votre dossier de projet et d' autres seulement des dossiers spécifiques de votre ordinateur .

— V. Panchenko
source