Utilisation dans le monde réel de l'Mercurial avec un Serveur Team Foundation server?

Ne sais 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:

1. 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)

2. Chaque fois que j'ai besoin de faire un changement, je clone mon "maître" repo et faire mon travail là-bas. 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 à tous. 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:

1. Le plus important est le fait que TFS est moche à trouver des changements. Il y a un 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

2. 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 j'ai peut sans opérer de 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 comme @Eric Hexter points dans les commentaires, vous pouvez utiliser le rebase extension pour 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 la l'effondrement de l'extension pour é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 post 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 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 purge de l'extension et 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.

@Eric, votre post à lostechies a été la plus utile. Avec VS2010, j'ai dû ajouter des options /diff et /supprime à la tftp en ligne de commande dans la commande de script pour obtenir modifiés et supprimés des fichiers archivés dans TFS. Au départ, j'étais une erreur de push quand un fichier a été supprimé (de travail) que hg mise à jour est

"impossible de supprimer FileXyz : l'accès est refusé".

J'ai installé le MakeWritable.py l'extension mais qui ne fonctionne que lors de l'ouverture des fichiers non supprimés. J'ai donc ajouté un appel à attrib pour supprimer la LECTURE SEULE de tous les fichiers dans le projet, puis de le restaurer par la suite (à l'exclusion de l' .hg dossier) j'ai aussi ajouté le /diff option, de sorte que les différences sont détectées par somme de contrôle MD5 au lieu de dépendre de l'attribut en LECTURE SEULE. Semble fonctionner correctement maintenant.

=====FILE: push.ps1=====
$projName = "TicTacToeCMMI"
$tftp = "C:\Program Files\Microsoft Team Foundation Server 2010 Power Tools\TFPT.exe"
$tf = "C:\Program Files\Microsoft Visual Studio 10.0\Common7\ide\tf.exe"

hg push
cd ..$projName-tfs  
"Syncing -tfs workspace with TFS server"  
&$tftp scorch /noprompt /exclude:.hg',_Resharper*',*.user  
"Making all files in -tfs writable"
attrib -R /S /D *
"Updating -tfs with latest push from Mercurial"
hg update -C -y
attrib +R /S /D *
attrib -R /S /D .hg\*
"Resyncing Mercurial changes with TFS Server"  
&$tftp online /adds /deletes /diff /exclude:'.hgignore,.hg,bin,obj,*.ps1,_Resharper*,*.lnk,*.user,*.suo,*.vspscc'  
"Checkin"  
&$tf checkin  
cd ..$projName-working  
cmd /c pause  

====FILE: pull.ps1=====
$projName = "TicTacToeCMMI"
$tf = "C:\Program Files\Microsoft Visual Studio 10.0\Common7\ide\tf.exe"
$username = cmd /c set USERNAME
$username = $username.SubString($username.IndexOf("=")+1)

function pull {
    cd ..$projName-tfs
    &$tf get
    hg commit -A -m "from tfs" --user $username
    cd ..$projName-working
    hg pull --rebase
}
pull  
cmd /c pause  

J'ai eu un peu d'une courbe d'apprentissage avec des scripts PowerShell qui je n'avais pas utilisé avant. Pour d'autres, comme moi, les scripts sont exécutés avec un raccourci comme ceci:

TARGET: C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe C:\dev\TicTacToeCMMI-working\push.ps1
START IN: C:\dev\TicTacToeCMMI-working

- Je mettre push et pull raccourcis sur ma barre des tâches afin de pousser/tirer vers/à partir de TFS est un seul clic

Si vous voulez être en mesure de travailler avec un DVCS et TFS, je crois que le meilleur moyen est d'installer le SVNBridge de TSF, et l'utilisation Bazar, qui est, autant que je sache, la seule DVCS qui s'intègre facilement avec SVN, et depuis votre TFS ressemble maintenant à un SVN, vous magiquement obtenir Bazar/TFS intégration

Je " il vient de mettre en place un petit outil, HgTfs, qui tente d'atteindre le but de la synchronisation Mercurial et TFS dépôts. C'est vraiment simple et et a seulement trois commandes: clone, tirer et pousser. Voici mon Bitbucket repo:

https://bitbucket.org/thepretender/hgtfs

Il y a aussi un post de blog décrivant le flux de travail et les scénarios d'utilisation (en fait, les pages wiki sont que des pièces de cette entrée de blog):

http://www.olegtarasov.me/Post/2013/07/Mercurial-to-TFS-bridge-(hgtfs)

Le code est hacky, mais il semble pour obtenir le travail fait. J'apprécierais vraiment des commentaires ou des fourches 🙂