Suggestions pour la maintenance des fichiers de projet Visual Studio vcproj dans le contrôle de version

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

Question

Microsoft Visual Studio utilise XML pour enregistrer ses fichiers de projet .vcproj . Les différents fichiers de projet XML devraient être facilement

.

Malheureusement, si vous modifiez les propriétés du fichier de projet, Visual Studio insiste pour que les nœuds XML du fichier de projet soient mélangés de manière aléatoire! Cela rend fondamentalement impossible la différenciation textuelle et la fusion des modifications de fichiers de projet. En modifiant un paramètre du compilateur, mon outil de comparaison visuelle peut penser que j'ai modifié 50% des lignes du fichier! J'ai même essayé des outils de diff XML, mais ils ne font que montrer une vue plus structurée du même désordre.

Quelqu'un a-t-il des suggestions pour conserver les fichiers .vcproj dans le contrôle de source? Ou un moyen de convaincre Visual Studio de ne pas réorganiser les noeuds XML dans le fichier .vcproj ?

(J'ai également utilisé des outils tels que CMake pour générer des fichiers .vcproj à partir d'un fichier texte plus convivial, mais CMake a ses propres problèmes.)

Était-ce utile?

La solution

Cela semble arriver de temps en temps.

C’est peut-être un problème qui pose problème pour un plug-in ou un autre outil de normalisation.

Ce serait une excellente activité secondaire, jusqu'à ce que MS décide de le réparer. Dans ce cas, vous n'avez pas de chance - à moins bien sûr qu'ils proposent d'acheter votre adresse IP.

Quelqu'un veut-il démarrer un projet open source ou un produit commercial? Je suis en jeu.

Je pourrais essayer un outil de normalisation autonome, puis voir si je peux le transformer en plugin.

Autres conseils

Nous voyons cela maintenant au travail, avec des fichiers de projet où les configurations sont réorganisées sur des ordinateurs de plusieurs personnes, et c'est très frustrant ...

* Remarque: Nous utilisons tous VS 2008 Pro, et non l'équipe

.

Au début, on dirait qu'ils ont été réorganisés de manière aléatoire, mais il existe en fait un motif qui n'est pas aléatoire du tout.

Pour un groupe, les configurations sont classées par plate-forme, puis par config:

  • Debug | Win32
  • Débogage | x64
  • Publication | Win32
  • Publication | x64
  • Déboguer DX11 | Win32
  • Déboguer DX11 | x64
  • Libérez DX11 | Win32
  • Publiez DX11 | x64
  • ...

Pour l'autre groupe, les configurations sont classées par Config, puis par Platform:

  • Debug | Win32
  • Publication | Win32
  • Déboguer DX11 | Win32
  • Libérez DX11 | Win32
  • Débogage | x64
  • Publication | x64
  • Déboguer DX11 | x64
  • Publiez DX11 | x64
  • ...

Si vous parcourez l'historique, vous constaterez qu'il s'agit de plusieurs projets soumis par les mêmes groupes de personnes. La répartition est divisée à 50/50 environ. Cela ne concerne donc pas qu'une seule personne.

Est-ce le même problème que vous voyez tous? Si tel est le cas, j’espère que ce modèle aidera à trouver une solution qui ne comporte pas d’étape macro / extra diff ...

Ce doit être un paramètre quelque part ou un effet secondaire du clic sur quelque chose, car il est reproductible à 100% pour chacune de ces machines. Même si c’est quelque chose de ridicule, comme quelle option choisir pour la configuration de votre environnement initial (VC ++, VB, Développement général, etc.)

J'utilise WinMerge comme outil de diff et j'ai activé la détection de bloc déplacé. Cela ne résout pas le problème, mais cela rend un peu plus supportable la visualisation des différences.

Dans quelle version de Visual Studio voyez-vous cela?

Je travaille beaucoup avec les fichiers .vcproj (nous conservons les versions des fichiers de projet de nos bibliothèques dans plusieurs versions de Visual Studio et je diffère et fusionne constamment), mais je n’ai jamais vu ce comportement.

Mon équipe chez Adobe a vu la même chose en vs2008. Juste un projet de base Debug / Release, win32 / win64 vous donne 4 configurations et un brassage aléatoire. Plusieurs personnes ont essayé de comprendre quand et pourquoi devstudio réorganise, mais on pense actuellement que la clé de tri est un hachage de mot clé - donc semi-aléatoire. Nous avons abandonné et dans les revues de code, nous résumons simplement le " real " changements.

Je pense avoir trouvé la raison de ce remaniement. Au moins dans VS2008.

Si vous installez les compilateurs x64, VS commandera les projets comme suit: 

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

Si vous ne le faites pas, il les commandera comme: 

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

Assurez-vous donc que le même ensemble de compilateurs est installé sur tous vos pairs, afin qu'il ne soit pas mélangé.

Il a été testé et ce comportement semble être reproductible.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top