TFS: fusion de nouveau dans la branche principale

lorsque vous cliquez sur Résoudre un conflit individuel, que dit le message sommaire? Si vos fusions de Current - > Experimental ont été complétées sans travail manuel majeur, cela devrait être quelque chose comme "X source, 0 cible, Y Les Deux, 0 conflictuel."En d'autres termes, il n'y a pas de blocs de contenu dans le fichier cible (courant) qui ne sont pas déjà dans la copie de la branche source (expérimentale). Vous pouvez utiliser le bouton AutoMerge All en toute sécurité.

Note: AutoMerge devrait être en sécurité, peu importe. Il est optimisé pour être prudent sur les alertes précoces, pas pour la capacité de résoudre chaque cas. Mais je reconnais que beaucoup d'entre nous -- moi-même inclus -- aiment allumer l'outil de fusion quand il y a une question. Dans le scénario décrit, IMO, même le plus nerveux peut se reposer facilement.

Pourquoi est-il un conflit? Et si le résumé de message n'est pas donc coupé et sec? Heureusement que vous avez demandé :) réponse courte - parce que le calcul que détermine l'ancêtre commun ("base") des fichiers connexes dépend fortement de la façon dont les conflits de fusion entre eux ont été résolus. Exemple Simple:

1. mettre en place deux branches, A et B.
2. faire des modifications à un\foo.cs et b\foo.cs dans des parties différentes du fichier
3. fusionner A - > B
4. automatiser le conflit
5. fusionner B - > A

TFS doit signaler cette séquence d'événements comme étant en conflit. La plus proche commune ancêtre entre B\foo.cs; 4 et a\foo.cs; 2 se trouve tout le chemin du retour à l'étape 1, et les deux côtés ont évidemment changé depuis.

il est tentant de dire que A & B sont synchrones après l'étape 4. (Plus précisément: l'ancêtre commun de la fusion de step 5 est la version #2). Sûrement une fusion de contenu réussie implique que b\foo.cs contient tous les changements apportés à ce jour? Malheureusement, il ya un certain nombre de raisons, vous ne pouvez pas supposer ceci:

• Généralités: Non tous les conflits qui peuvent être AutoMerged. Vous avez besoin de critères qui s'appliquent aux deux scénarios.

• exactitude: même si AutoMerge réussit, il ne génère pas toujours du code valide. Un exemple classique se produit lorsque deux personnes ajoutent le même champ à différentes parties d'une définition de classe.

• flexibilité: chaque utilisateur de contrôle source a ses propres outils de fusion préférés. Et ils ont besoin de la capacité de continuer le développement / test entre la résolution initiale décision ["besoin de fusionner le contenu d'une certaine façon, un jour"] et la finale de l'Archivage ["ici, cela fonctionne"].

• Architecture: dans un système centralisé comme TFS, le serveur ne peut tout simplement faire confiance qu'à sa propre base de données + les exigences de validation de L'API. Tant que l'entrée est conforme aux spécifications, le serveur ne devrait pas essayer de distinguer comment divers types de fusions de contenu ont été effectuées. (Si vous pensez que les scénarios jusqu'à présent sont facilement distingués, considérer: quelle si le moteur AutoMerge a un bug? Qu'arrive-t-il si un client malhonnête appelle le webservice directement avec un contenu de fichier arbitraire? Seulement gratter la surface, ici...les serveurs doivent être sceptique pour une raison!) Tout ce qu'il peut calculer en toute sécurité est vous m'avez envoyé un fichier résultant qui ne correspond pas à la source ou à la cible.

en regroupant ces exigences, vous vous retrouvez avec une conception qui regroupe nos actions à l'étape 4 dans une catégorie assez large qui comprend également les fusions manuelles résultant d'un chevauchement d'éditions, les fusions de contenu [automatiques ou non] fournies par des outils tiers, et les fichiers édités à la main après le fait. Dans la terminologie de TFS, c'est un AcceptMerge résolution. Une fois enregistrées en tant que telles, les règles de la fusion(MC) doivent assumer le pire dans la poursuite de l'intégrité historique et la sécurité des opérations futures. Dans le processus vos intentions sémantiques pour L'Étape 4 ("pleinement incorporer dans B chaque changement qui a été fait à A dans #2") ont été réduits à quelques octets de la logique pure ("donner à B la suite de nouveaux contenus + crédit pour la manipulation n ° 2"). Bien que regrettable, il est "juste" un problème UX / éducation. Les gens sont beaucoup plus en colère lorsque les règles de la fusion font de mauvaises hypothèses qui conduisent à code cassé et la perte de données. En revanche, tout ce que vous avez à faire est de cliquer sur un bouton.

FWIW, il y a beaucoup d'autres fins à cette histoire. Si vous choisissez Copier depuis la branche Source [alias Acceptttheirs] à l'étape 4, il n'y aura pas de conflit à l'étape 5. Idem si vous a choisi une résolution AcceptMerge mais s'est trouvé à propager un fichier avec le même hachage MD5 qu'un\foo.cs; 2. Si vous choisissez de garder la cible [alias AcceptYours] à la place, les conséquences en aval changent encore une fois, bien que je ne me souvienne pas des détails pour le moment. Tout ce qui précède devient assez complexe lorsque vous ajoutez d'autres types de modifications (en particulier renommer), fusionnez des branches qui sont beaucoup plus hors de la synchronisation que dans mon exemple, choisissez certaines gammes de versions et traitez avec les orphelins plus tard., etc....

EDIT: comme le destin l'aurait voulu, quelqu'un d'autre vient de poser la même question sur le forum MSDN. Comme tend à être ma nature, je leur ai écrit une autre longue réponse qui est sorti complètement différent! (bien que touchant évidemment sur les mêmes points clés) espérons que cela aide: http://social.msdn.microsoft.com/Forums/en-US/tfsversioncontrol/thread/e567b8ed-fc66-4b2b-a330-7c7d3a93cf1a