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 que ses modifications deviennent des conflits sur le fichier de solutions de projet qui ne sont pas faciles à Fusionner.
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égrate mes propres changements. En fonction de la quantité de nouveaux fichiers ajoutés au projet, cela peut être facile ou une tâche vraiment gênante.
Je me demande s'il y a un moyen plus facile de le faire. Lire: Puis-je faire vs / tfs / fusionner le faire pour moi?
5 Réponses :
Ma suggestion serait de mettre à jour et de s'engager plus fréquemment. En particulier, assurez-vous d'exécuter Devez DERNIER avant de passer des modifications sur un fichier de solutions.
"Fusionner l'enfer" avec des éléments tels que XML et les fichiers texte (que tous les fichiers de projet et de solution sont) ne se produit généralement que parce que les personnes essaient de commettre des changements simples qui sont très grands.
Si vous prenez l'habitude de faire des engagements réguliers, les fonts ont tendance à être plus petits, et les outils ont tendance à y faire un travail parfait.
Je suggérerais également que vous obtenez votre peuple à l'aise avec l'arrêt et l'abandon des questions s'ils ne savaient pas comment fusionner un fichier de solutions. J'ai travaillé à un endroit où plusieurs fois par semaine, je devrais nettoyer manuellement le fichier de solution parce que les gens se réalisaient au lieu de vérifier les résultats. (Et le SLN n'est pas XML.)
@Reed, je dois être en désaccord. Avez-vous réellement exécuté un outil de réalisation automatiquement contre un fichier * .sln où deux personnes ont ajouté de nouveaux projets? Il n'ya littéralement aucun moyen de réussir à cause de la façon dont les projets sont attribués.
@Richard: Si vous mettez à jour et que vous vous engagez fréquemment, cela ne devrait jamais arriver. Personnellement, je rends mon équipe toujours à jour avant un commit. Personnellement, j'estime qu'un nouveau projet ajouté devrait être un commit tout cela est propre. Cela signifie que vous mettez à jour, commettent tout changement. Ajoutez ensuite votre projet et commettez cela. Fondamentalement, vous ne devriez jamais avoir deux "nouveaux" projets à fusionner, à moins que deux personnes essaient d'ajouter un nouveau projet dans les mêmes délais de minute (très improbable) ...
@Richard: Si vous essayez de fusionner un seul projet étant ajouté à la .sln, cela fonctionne bien. Je fais ça tout le temps...
@Reed - la mise à jour avant de commettre ne change rien. Voici la séquence problématique: (1) A ajoute un projet localement (2) B ajoute un projet localement (3) un engagement. À ce stade, peu importe ce que B fait; Mettre à jour et commit [Aka Get & Checkin in TFS Lingo] déclenchera exactement le même conflit. Et cela lui obligera à éditer à la main le fichier SLN ou à renvoyer + réappliquer ses modifications.
@Richard: Avez-vous lu mon commentaire entier? Je conviens que cela peut être un problème, mais si vous êtes commis régulièrement, cela ne se produit que si deux personnes essaient d'ajouter un projet dans la même fenêtre de validation. Personnellement, je pense que l'ajout d'un projet devrait être son propre commit, de sorte que la fenêtre devrait être comme une fenêtre de 5 minutes - très improbable deux personnes ont besoin d'ajouter un nouveau projet dans les mêmes minutes ...
@Reed: Je suppose que vos développeurs ont une sorte de processus d'arrière-plan / déclencheur qui fonctionne deviennent les plus récents toutes les 5 minutes? Oui, cela limiterait le problème à une fenêtre de 5min au pire. Mais je ne pense pas que cette méthodologie est très courante (ni pratique sur les grands serveurs).
@Richard Vous n'avez pas besoin de recevoir les dernières toutes les 5 minutes. Le DV qui ajoute les premières mises à jour du projet (en garantissant qu'il dispose de la dernière version du SLN ainsi que de tout projet ajoute d'autres devs ont fait), ajoute son projet à la solution, puis s'engage. C'est la fenêtre de 5 minutes dont il se réfère. Il n'y a qu'un problème si deux devs ajoutent un projet indépendamment dans cette fenêtre de 5 minutes, et même à ce moment-là, il est aussi simple que de faire une mise à jour, ré-ajoute mon projet et commettre.
OK, la contrainte est donc "Toujours fonctionner pour en attendre des modifications de la solution". Assez juste.
Ajout de cet avis spécifique à la réponse de Reed afin que je puisse changer de vote.
@Richard: Cela, et "toujours commettre immédiatement après avoir changé la solution". Entre les deux choses, mon équipe actuelle n'a jamais eu un seul problème qui nécessitait la modification des mains du fichier de solutions. Avant de faire ça, c'était un cauchemar constant ...
Je n'ai jamais ajouté de fichiers à la solution, seuls des projets. Si vous devez ajouter des fichiers, ajoutez-les à un projet.
Si vous ne voulez pas fusionner, l'alternative est que si une personne vérifie une solution avec un nouveau projet, puis tirez ce projet et la solution en bas, écrasant votre propre fichier de solutions, puis ajoutez votre projet à la Solution et vérifiez que vous rentrez. Maintenant, la solution a à la fois son projet et votre votre projet.
Certains fichiers sont agréables d'avoir une solution comme référence. Des exemples que j'ai utilisés dans le passé seraient des assemblées de tiers, des clés de nommage fortes, des notes générales et des 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 vous empêcher d'avoir des incohérences entre machines. Lorsque vous consultez la solution et les fichiers sur une autre machine, ils peuvent ne pas être dans la même structure de répertoire relatif qu'elles étaient pour le développeur qui ont ajouté les fichiers. Les solutions permettent également de références à des fichiers tels que ".. \ \ westfolder" qui peuvent créer des ravages lorsqu'un autre développeur tente de tirer la solution du contrôle de la source.
Je suis d'accord avec Aaronis que vous devez faire attention avec des chemins relatifs. Cependant, il est assez normal d'ajouter des assemblées tierces à la solution à mesure que Matthew explique. Ce que je fais toujours, c'est créer un répertoire nommé 'assemblys partagés' pour les DLL 3ème partie dans le répertoire de solutions et créer un dossier de solution avec ce même nom. De cette façon, je n'ai jamais aucun des problèmes d'Aaronis décrit.
C'est exactement ce que je fais déjà, mais j'espérais qu'il y avait une meilleure façon :)
Une suggestion d'ajouter au pool de commentaires ...
Travaillez à minimiser les modifications que vous apportez au fichier SLN lorsque vous vous engagez, afin de faciliter les autres de fusionner. strong> (bien sûr, la même chose va aussi pour les autres aussi). P> Pour illustrer, supposez que votre fichier SLN répertorie actuellement quatre projets: P> SLN: A, B, C, D, E
Co-Worker: A, B, C, D, F
Moi aussi, j'en ai beaucoup marre avec des problèmes de fusion avec des fichiers de projet. (À un moment donné, j'essayais de résoudre plus de 9 000 conflits dans un seul fichier de projet.)
Alors j'ai fait quelque chose à ce sujet: http://www.projectmerge.com
Bien que cela ait démarré en tant qu'outil de comparaison / fusion de fichier de projet, il a rapidement évolué dans quelque chose qui peut comparer et fusionner tout fichier XML.
J'espère que vous le trouverez utile.
J'ai fait un outil spécifiquement pour comparer / fusionner le fichier de solution (et peut également être utilisé pour créer de manière dynamique une solution filtrée également).
On se trouve à l'adresse suivante: http://slntools.codeplex.com/
Je viens de m'a sauvé beaucoup de telle ami. Merci :)
Quel est difficile de fusionner des fichiers XML?
La fusion automatique n'est pas trop mauvaise pour la gestion des fichiers de projet de mon expérience et offre cette option pour vous (que vous rejetez actuellement!).
À 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 aménagée à l'avance. Peut-être devriez-vous même en faire une règle que les développeurs devraient poser à la senior Dev ou à l'architecte si un projet peut être ajouté. Même l'ajout de fichiers doit être assez rare.
@Joel - Les fichiers * .SLN ne sont pas XML. Ils sont un avortement d'un format de fichier lorsque l'ordre et la numérotation sont importants de manière indessitante des façons stupides.
@Richard - Alors ils sont. Je suppose que vous réfléchissez à des fichiers de projet, non de fichiers de solution, en raison de la phrase "nouveaux fichiers ajoutés au projet".
@Steven j'ai essayé cette option beaucoup de fois, mais elle n'a jamais réussi à résoudre les fantasmes automatiquement. @Dan fusion de fichiers XML n'est pas un biggy, mais si vous voyez que le contenu est bourré de GUIDS et qui sait quel type de vérification de la validité, des compteurs, etc. Je n'ai pas vraiment envie de tenter ma chance pour simplement gifler les 2 fichiers.