Vous ne savez pas si c'est quelque chose que vous ne connaissez pas déjà, mais j'ai été en utilisant mercurial localement pour un peu de temps maintenant, et jusqu'à présent, je pense que les avantages sont clairement supérieurs aux ajoutés à la gestion de deux systèmes de contrôle de source. Voici comment j'ai été faire les choses:
J'ai fait mon TFS checkout un HG référentiel, que je considère comme mon "maître". Je reçois des mises à jour de TSF et de les engager à ce repo, il contient la plupart des état actuel du projet de TFS. La chose importante ici est qu'il n'y a pas de changements de ce fait indépendant de TFS mise à jour ou un Hg merge (qui est la partie 2)
Chaque fois que j'ai besoin de faire un changement, je clone mon "maître" repo et faire mon travail. J'ai trouvé que d'un clone par fonction ou une histoire est en fait assez facile à gérer, et se sent assez propre. Une fois que j'remplir une fonction, je ne l'Hg merge de retour pour le "maître" repo, qui a eu tous de la TSF à une mise à jour. Ceci me permet d'utiliser la Mercuriels les capacités de fusion, qui sont donc de loin supérieure à la TSF à remettre en question la façon dont TFS peut prétendre à un code de fusion. Une fois la fusion terminée, je m'engage dans Hg, puis vérifier ces changements dans TFS. La meilleure partie de cela est que lorsque je fais le check in à TFS, je n'ai pas à fusionner quoi que ce soit. Très, très beau.
Maintenant, voici les questions que j'ai trouvé avec cette approche:
Le plus important est le fait que TFS est moche à trouver des changements. Il est de rendre accessible en écriture plugin que vous pouvez utiliser pour faire de la modification de fichiers accessible en écriture lorsqu'ils sont mis à jour/fusion Mercurial. Il y a deux options que j'ai trouvé pour cela. Vous pouvez soit la force TSF aller hors ligne, qui sera supposer quoi que ce soit accessible en écriture doit être vérifié, ou vous pouvez utiliser l'outil de comparaison dans le contrôle de source de l'outil et sélectionnez les fichiers modifiés et individuellement les vérifier. Les deux sont de merde de l'OMI
Le contrôle de la source de liaisons sont toujours là au niveau du projet, même si on exclut les TFS de contrôle à la source des fichiers à partir de votre hg référentiel (ce qui devrait le faire). Ce n'est pas entirly évident jusqu'à ce que vous ajoutez un fichier à la solution, à laquelle il tente de l'ajouter à la source de contrôle. Vous pouvez Annuler les Modifications en Attente" et de se débarrasser de la source de contrôle à ajouter, mais c'est vraiment ennuyeux.
La bonne nouvelle, c'est que j'ai utilisé cette approche pour travailler à travers une assez massives de fusion qui, je pense, aurait dû me tourner vers une forme de drogues dures, si j'avais été forcé d'utiliser le TSF des outils pour le faire.
Je n'ai pas encore appliqué cette mise à jour de branches dans TFS, mais j'imagine qu'il serait beaucoup mieux que les options qui vous sont donnés pour la fusion dans TFS. Sur une note connexe, puisque vous pouvez le vérifier en morceaux de la fonctionnalité de travail à un moment donné, à l'aide de la TSF de fusion serait moins problématique tout simplement parce que tous les changements nécessaires pour une fonction serait de rassembler dans un seul endroit.
Une chose que je n'ai pas essayé de lutter contre le partage de ce à travers l'ensemble de l'équipe. Partie de la raison en est qu'il n'a vraiment pas à être une équipe à l'échelle chose. Je travaille à distance, afin d'avoir un référentiel local est une grosse affaire, et permet d'économiser beaucoup de temps. Les autres membres de mon équipe de dev peut ou ne peut pas obtenir les mêmes avantages de cette approche, mais je le trouve assez cool que je peux , sans affecter la façon dont ils travaillent.
Mise à jour
J'ai eu envie de mettre à jour cette réponse pour un certain temps avec des informations supplémentaires sur la base des observations et certaines de mes expériences de travail avec de grandes TFS dépôts.
D'abord en tant que @Eric Hexter points dans les commentaires, vous pouvez utiliser le rebase extension de mieux intégrer les commits de votre travail dépôts dans votre principal TFS référentiel. Bien que, selon la façon dont vous voulez que votre s'engage à apparaître à TFS, vous souhaiterez peut-être utiliser l' effondrement de l'extension de l'écraser vos modifications dans un seul commit (cela peut faire des restaurations dans TFS plus facile). Il y a aussi le "en ligne" commande à partir de TFS PowerTools qui peut rendre le travail de laisser TFS savoir ce qui a changé plus facile (merci encore à Eric pour mentionner que, dans son billet de blog)
Maintenant, quand j'ai d'abord écrit ce que je travaillais sur un projet qui n'a qu'un TFS branche que les développeurs ont été à l'aide, et était assez petit, donc le clonage des dépôts était pas une grosse affaire. Plus tard, je me suis retrouvé à travailler sur un projet qui a une pension qui a été d'environ 1,5 GO après le départ, et beaucoup plus grand après la construction, et a impliqué la commutation entre les branches dans TFS assez souvent. Évidemment, cette approche n'est pas adaptée à cet environnement (en particulier car à un moment il a été impossible de construire des solutions dans un répertoire particulier.
Le problème de taille est mieux traité en utilisant une technique similaire à gits sujet branches plutôt que de cloner le dépôt de nouveaux répertoires. Il ya un couple d'options pour cela. Je pense que le mieux est effectivement d'utiliser le signet d'extension et de créer un sujet "signets", plutôt que le sujet branches. Vous pouvez utiliser les branches nommées en tant que bien, mais ils ont le léger inconvénient d'être permanente, et de voyager avec tout les clones vous pouvez le faire (si vous voulez partager votre chouette TFS-Hg hybride avec un collègue). Les signets sont des locaux pour votre repo, et de manière efficace du point de validation et de voyager avec la tête. Ils sont mis en œuvre de sorte qu'ils peuvent être utilisés dans un endroit où Hg s'attend à une révision (donc, de fusions, de mises à jour, etc). Vous pouvez les utiliser pour créer un TFS signet en tant que votre principale "de branche" qui ne reçoit que des mises à jour de TSF, et se confond à partir de la rubrique travaux, qui auraient chacun leurs propres signets, et vous pouvez supprimer une fois que vous avez commis retour à la TSF. Si vous utilisez plutôt les branches nommées, alors vous pouvez appliquer exactement les mêmes techniques, ce qui est pratique.
Maintenant, les multiples branche problème est plus délicat, surtout depuis TFS "branches" sont en fait des copies de chaque fichier à partir de l'original de la branche, ce qui signifie que chaque fois que vous tirez dans les branches de TSF, votre pension est d'obtenir beaucoup plus grand. Une façon possible de traiter cette question est d'utiliser une combinaison de nommé Hg branches, et des signets, de sorte que vous avez une branche pour chaque TFS branche, puis de créer des signets pour vos travaux de ces branches. Le véritable casse-tête dans ces scénarios est en fait traiter avec TFS espaces de travail à travers tout cela. Vous pouvez supprimer les mappages dans vos espaces de travail et obtenir assez loin, mais une fois que vous carte dans votre répertoire de travail, vous devez être prudent de TSF de buter sur des fichiers (c'est effectivement là où le TF PowerTools en pratique). Essayer de quitter l'espace de travail attaché tout de commutation branches devient laid rapide. Quelques outils qui sont agréables à avoir dans votre toolbelt sont les Hg de purge de l'extension et de la TF PowerTools "brûlures" de commande. Les deux effectivly supprimer des fichiers qui ne sont pas dans le contrôle de version (techniquement "scorch" s'assurer de la TSF et de votre répertoire local de travail de match, de sorte qu'il puisse mettre à jour les fichiers).
Pour moi, cependant, ce processus est devenu très lourd et sujettes à erreur. J'ai récemment opté pour l'utilisant git avec git, tfs, puisqu'elle gère TFS espaces de travail pour moi, et enlève beaucoup de la charge découlant de ce côté. Malheureusement, il ne semble pas être un "hg-tsf" là-bas n'importe où, ou j'aurais probablement choisi.
