TortoiseSVN et Visual Studio Express 2010

Question

J'utilise le client TotoiseSVN et Assembla backend dans un projet express VS 2010. Nous avons des problèmes avec la suppression de dossiers (ou filtres) VS et l'ajout de fichiers au projet. Je remarque que lorsque je committe les fichiers .vcxproj et .vcxproj.filters ne sont jamais cochés par défaut même s'ils devraient changer. Donc, je les vérifie manuellement et dit aux autres aussi bien quand ils s'engagent.

Cela peut conduire à des problèmes si membre de l'équipe A vérifie, seules les modifications du code, alors que membre de l'équipe B a le projet vérifié et les fichiers ajoutés au projet. Si le membre de l'équipe B commet AVANT le membre de l'équipe A, le nouveau membre de l'équipe A n'a pas ajouté le nouveau fichier B de l'équipe A, son projet remplace le fichier de projet B qu'il a archivé et maintenant les nouveaux fichiers ajoutés ne sont pas inclus. le projet.

Comment pouvons-nous contourner cela en plus d'avoir une coordination incroyable?

Answer 1

CMake est parfait pour cela.

Si vous ne l'avez pas rencontré CMake, il vous permet de créer vos fichiers ensemble du projet de construction dans un répertoire distinct à vos fichiers source, en dehors de svn tout à fait.

Un seul fichier CMakeLists.txt dans la racine de votre répertoire remplacerait tous vos fichiers .vcxproj et .filters actuels.

Answer 2

Je soupçonne que ce qui peut se produire ici est que les développeurs ne sont pas enregistrer les fichiers de projet lors de l'ajout de nouveaux fichiers à leur disposition. VS2008 l'a fait par défaut, mais je pense que dans VS2010 ils ne sont pas sauvegardés tant que vous n'avez pas fait explicitement Fichier -> Enregistrer tout. En conséquence, cela signifie que les changements ne sont pas engagés. Une fois que vos devs font prendre l'habitude de sauvegarder les fichiers du projet avant de s'engager, alors SVN va dans 99% des cas gérer toutes les fusions pour vous. Le 1% restant du temps est quand quelqu'un a fait une restructuration plus importante du fichier de projet ou deux personnes ont apporté des changements contradictoires aux paramètres de construction. Dans ces cas, vous devrez les résoudre à la main.

SVN ne sera jamais remplacer un changement de personne avec une autre, il sera toujours essayer de fusionner. Ainsi, si vous rencontrez ce problème, cela suggère qu'une personne annule les modifications de quelqu'un d'autre ou ne dispose pas de l'option dans Visual Studio de recharger les fichiers en cas de modification externe: Tools -> Options -> Documents -> Detect when file is changed outside the environment.

Un moyen efficace de résoudre ce problème consiste à configurer un serveur de construction simple, par exemple avec Jenkins qui lance une construction périodiquement après quelques vérifications. Si la construction échoue alors la personne qui s'est enregistrée reçoit un courrier pour leur dire qu'ils ont cassé la construction. Vous pouvez également avoir un moniteur qui montre le build status qui rend les constructions cassées plus visibles à toute l'équipe et, nous l'espérons, encourage tout le monde à garder la construction corrigée.