Visual Studio 2008: comment éviter l'enfer de fusion de fichiers de projet?

Lorsque vous travaillez sur un projet VS C# avec plusieurs développeurs qui ajoutent tous de nouveaux projets et fichiers à la même solution, le dernier à essayer de vérifier ses modifications obtient des conflits sur le fichier de solution du projet qui ne sont pas faciles à fusionner .Visual Studio 2008: comment éviter l'enfer de fusion de fichiers de projet?

La solution la plus simple à ce problème que j'ai trouvé est de rejeter mes propres changements et d'accepter la dernière version du serveur. Ensuite, je réintègre mes propres changements. Selon la quantité de nouveaux fichiers ajoutés au projet, cela peut être facile, ou une tâche vraiment ennuyante.

Je me demande s'il existe un moyen plus simple de le faire. Lire: puis-je faire VS/TFS/fusion faire cela pour moi?

Source

2010-03-16 n3wjack

Ce qui est difficile de fusionner des fichiers XML? –

Fusion automatique n'est pas trop mal à gérer les fichiers de projet dans mon expérience, et il offre cette option pour vous (que vous êtes en train de rejeter!). –

À quelle fréquence ajoutez-vous des projets? L'ajout de projets à une solution ne devrait pas être une tâche quotidienne lorsque votre architecture est présentée à l'avance. Peut-être que vous devriez même faire une règle que les développeurs devraient demander au principal développeur ou architecte si un projet peut être ajouté. Même l'ajout de fichiers devrait être assez rare. – Steven

Ma suggestion serait de mettre à jour et de commettre plus fréquemment. En particulier, assurez-vous de lancer Get Latest avant d'attendre toute modification sur un fichier de solution. "Merge Hell" avec des choses comme XML et les fichiers texte (qui sont tous les fichiers de projet et de solution) se produit généralement uniquement parce que les gens essaient de valider des changements uniques qui sont très importants.

Si vous avez l'habitude de faire des commits réguliers, les fusions ont tendance à être plus petites, et les outils ont tendance à faire un travail parfait.

Source

2010-03-16 16:52:00

Je suggérerais également à vos employés d'arrêter de poser des questions s'ils ne savent pas comment fusionner un fichier de solution. Je travaillais à un endroit où plusieurs fois par semaine je devais nettoyer manuellement le fichier de solution car les gens s'automatisent au lieu de vérifier les résultats. (Et la SLN n'est pas XML.) –

@Reed, je ne suis pas d'accord. Avez-vous réellement exécuté un outil d'automerge contre un fichier de * .sln où deux personnes ont ajouté de nouveaux projets? Il n'y a littéralement aucun moyen de réussir en raison de la façon dont les numéros de projets sont attribués. –

@Richard: Si vous mettez à jour et commettez fréquemment, cela ne devrait jamais arriver. Personnellement, je fais toujours mettre à jour mon équipe avant un commit. Personnellement, je pense qu'un nouveau projet ajouté devrait être un engagement à part entière. Cela signifie que vous mettez à jour, validez les modifications. Ensuite, ajoutez votre projet et validez-le. Fondamentalement, vous ne devriez JAMAIS avoir deux "nouveaux" projets à fusionner, à moins que deux personnes essayent d'ajouter un nouveau projet dans le même laps de temps (très peu probable) ... –

Je n'ajoute jamais de fichiers à la solution, seulement des projets. Si vous devez ajouter des fichiers, ajoutez-les à un projet. Si vous ne voulez pas fusionner, l'alternative est que quelqu'un vérifie une solution avec un nouveau projet, puis écrase ce projet et la solution en écrasant votre propre fichier de solution, puis rajoute votre projet à la solution et vérifiez cela. Maintenant, la solution a à la fois leur projet et le vôtre.

Source

2010-03-16 16:54:16 AaronLS

Certains fichiers sont agréables pour avoir une solution comme référence. Les exemples que j'ai utilisés dans le passé sont les assemblages tiers, les clés de dénomination fortes, les notes générales et les fichiers de configuration partagés. –

Je les place dans un projet vide. Le problème est que les dossiers "virtuels" utilisés par les solutions peuvent provoquer des incohérences entre les machines. Lorsque vous extrayez la solution et les fichiers sur une machine différente, ils peuvent ne pas être dans la même structure de répertoire relative que pour le développeur qui a ajouté les fichiers. Les solutions permettent également de faire référence à des fichiers tels que ".. \ .. \ OutsideFolder", ce qui peut créer des dégâts lorsqu'un autre développeur tente d'extraire la solution du contrôle de la source. – AaronLS

Je suis d'accord avec aaronis que vous devez faire attention aux chemins relatifs. Cependant, il est assez normal d'ajouter des assemblages tiers à la solution, comme l'explique Matthew. Ce que je fais toujours est de créer un répertoire nommé 'Assemblées partagées' pour les DLLs tierces dans le répertoire de la solution et de créer un dossier de solution avec le même nom. De cette façon, je n'ai jamais aucun des problèmes décrits par Aaronis. – Steven

Une suggestion pour ajouter à la piscine des commentaires ...

travail sur la réduction des modifications apportées au fichier SLN lorsque vous vous engagez, pour le rendre plus facile pour les autres de fusionner.

(Bien sûr, il en va de même pour les autres).

Pour illustrer, supposons que votre fichier SLN contient présentement quatre projets:

SLN: A, B, C, D

Vous et un collègue de travail à la fois apporter des changements. Vous ajoutez projet E, plus (pour une raison quelconque) les choses se réorganisés:

Yours: A, E, D, C, B

Vos collègues changements impliquent l'ajout de projet F:

Co-Worker: A, B, C, D, F

Si vous vous engagez vos modifications est donc votre co -travailleur doit faire face à la fusion de ces deux:

SLN: A, E, D, C, B 
Co-Worker: A, B, C, D, F

Nasty.

Au lieu de cela, si vous (soigneusement!) Travailler pour minimiser vos différences, vous pouvez faire votre copie de travail ressembler à ceci:

Yours: A, B, C, D, E

Dans ce cas, lorsque votre collègue a besoin de fusionner, ils devront faire face à ceci:

SLN: A, B, C, D, E 
Co-Worker: A, B, C, D, F

Beaucoup plus facile à fusionner.

Source

2010-03-17 21:01:02 Bevan

J'étais trop marre de problèmes de fusion avec les fichiers de projet. (À un moment donné, je tentais de résoudre 9000+ conflits dans un seul fichier de projet.)

J'ai donc fait quelque chose: http://www.projectmerge.com

Bien que cela a commencé comme un fichier de projet de comparaison/fusion outil, rapidement évolué en quelque chose qui peut comparer et fusionner un fichier XML.

J'espère que vous le trouverez utile.

Source

2010-08-14 15:03:03

J'ai fait un outil pour spécifiquement comparer/fusionner le fichier de solution (et peut également être utilisé pour créer dynamiquement la solution filtrée ainsi).

Il peut être trouvé à: http://slntools.codeplex.com/

Source

2010-09-02 17:27:53

Wow merci je vais essayer ça. Souhaite moi bonne chance! – toddmo

Juste m'a sauvé beaucoup de headbanging. Merci :) –

Visual Studio 2008: comment éviter l'enfer de fusion de fichiers de projet?

Répondre

Questions connexes