Nous avons un projet TFS 2008 avec deux branches ("Main" et "NewFeature"). Chacune est une "copie" complète et indépendante (variante) du code source.
En modifiant les mappages de l'espace de travail, nous pouvons mapper une variante sur nos PC locaux et travailler avec les deux branches sans problèmes.
Toutefois, si je configurais les mappages pour commuter notre serveur de construction sur la branche NewFeature (qui devrait simplement échanger dans le code source NewFeature sans changer quoi que ce soit d'autre que le serveur de construction), je reçois des erreurs: IE Lorsqu'il s'agit de la branche NewFeature, quelque chose regarde toujours dans la branche J'ai effectué une version complètement propre (supprimé le dossier de construction du serveur et exécutez la construction avec / p: FORCEGET = true pour vous assurer que la cartographie est Vida sur le serveur et il n'y a pas de fichiers sur le serveur qui pourrait cacher les fixations d'espace de travail), mais cela n'aide pas. Toute suggestion?
6 Réponses :
Vérifiez que:
/ edit /
Note, cependant, il est pas important que $ / maintien de la main et des succursales / caractéristiques vivent au même niveau dans la hiérarchie des arbres. Le chemin local doit pas non plus sur le serveur de construction. * Tout ce qui compte, c'est ce qui est sous chaque branche. Si le contenu est cohérent en interne, tous vos scripts de construction existants doivent fonctionner sans modification.
Pour des exemples concrets de la façon dont j'aime bien attacher ensemble, voir mes réponses passées, par exemple:
Mon chemin n'est pas le seul moyen, mais je peux attester que cela fonctionne mieux que toutes les autres variations que j'ai rencontrées au fil des ans :)
* Franchement, essayant de la construction de l'équipe de micromanage peut devenir beaucoup plus douloureuse que la restructuration proposée à vos scripts Msbuild. Pour la fiabilité, vous devez placer votre TFSBUILDSERVICE.EXE.CONFIG Personnalisations Sous la version Control quelque part ... Si vous possédez> 1 Build Server (ou une puissance ultérieure), vous devez envisager une stratégie de déploiement de changement ... vous finissez par avoir besoin de Un processus Meta-SCM pour gérer votre processus SCM!
Merci Richard. Le problème est que nous avons une construction héritée qui fait des copies, l'obfuscation, les installateurs, puis une copie dans le dossier de chute après la construction - afin (pour économiser beaucoup de travail), j'ai vraiment espéré cartographier le code NewFeature à la place du code principal. . Je vais ajouter une réponse ci-dessous avec mes conclusions jusqu'à présent ...
Bravo pour Takig Le temps d'ajouter ce détail, Richard. Je vais avoir une bonne lu. Je veux juste trier les meilleures pratiques TFS avant de faire des changements énormes, plutôt que d'aller à beaucoup d'efforts, puis de découvrir que cela ne fonctionne pas de cette façon!
Réponse acceptée, comme vos autres réponses décrivent exactement ma structure de succursale prévue, suggérant que je suis au moins aboyer dans le bon arbre :-)
@Richard: Je viens d'avoir une autre fissure dans ce problème et je l'ai résolu proprement cette fois-ci. Il s'avère que vous étiez tache avec votre réponse, cela m'a pris un certain temps pour déterminer comment l'appliquer :-) Si vous êtes intéressé, j'ai posté une nouvelle réponse à cette question détaillant la situatine (au cas où quelqu'un sinon frappe le même problème à l'avenir).
Je sais que c'est vieux, mais j'ai aussi le même problème, essayant de construire une branche que j'ai téléchargée à partir de mon serveur TFS 2012. Bien que la succursale soit myProject_v1_0_0_1, lorsque je file de la mise en place de TFS, TFS se plaint et dit: il n'y a pas de mappage de dossier de travail pour $ / myProject / main / projet.sln. Comment dois-je "$ (solutiontobuild) utilise un chemin relatif lors de la référence de produit.sln"? Merci.
BTW, MyProject_v1_0_0_1 est mappé sur C: \ dev \ myProject_v1_0_0_1, pas C: \ dev \ myProject du tout.
OK, les résultats sont dans - j'ai trouvé une solution de contournement.
En raison de nos processus de construction Legacy (construction, copie, obfusez, construire des installateurs personnalisés, copier dans le dossier déposé), je ne peux pas facilement placer la branche à côté de la branche principale. Il doit remplacer it.
Donc, si j'ai la main et le nouveau-nouveau, je souhaite consacrer la main principale et la carte NewFeature à sa place (c.-à-d. Utilisez "C: \ Main" sur le serveur de construction et modifier simplement le code source qui l'apparaît)
Résultat attendu: la structure de code NewFeature remplace simplement la principale, et le serveur de construction ne sait pas que c'est sur une branche différente.
Résultat réel: échec avec un "Vous n'avez pas été mappé $ / MAIN, même si vous n'êtes pas l'utilise" Erreur.
Ceci fonctionne (il supprime l'avertissement et permet ainsi la construction de procéder à Msbuild ignorant qu'il construit dans une branche). Cependant, c'est moche et la construction obtient inutilement tout le code source de la branche principale.
J'espère que je peux alors cartographier uniquement la branche que j'ai besoin et modifier Tfsbuild.Proj pour la rediriger pour construire dans cette branche.
(éditer: Oui, cela fonctionne bien. Nous avons maintenant réorganisé toute notre structure de code de sorte que tout (toutes les branches) soit sous une racine commune dans un seul projet d'équipe et que la ramification / le bâtiment n'est plus un problème. - Il est facile de faire tout ce dont nous avons besoin maintenant. L'astuce consiste à insérer un dossier racine dans la hiérarchie afin que vous puissiez agir à n'importe quel niveau que vous aimez. J'ai ajouté un petit tweak au script de construction afin que nous puissions passer la branche Pour construire comme paramètre à Msbuild, il est donc facile de construire une variante maintenant. Toute branche que nous ne voulons pas travailler peut simplement être masquée et que le serveur de construction reste heureux.)
résumé
Toutes ces solutions (pour utiliser le terme technique) sucer. Vous devez remapper l'espace de travail (dans ce cas, ce n'est pas simple: 9 Les entrées de mappage sont nécessaires pour que ce soit une erreur sujette et fastidieuse à faire), modifiez Tfsbuild.proj, supprimez tout le code source et exécutez une construction avec / p: forcerget = true pour changer la construction entre les branches. Il faut donc environ une heure pour changer de branches. Incroyable - cela devrait prendre quelques minutes au plus!
Je réalise que notre projet est loin d'être idéalement mis en place, mais je ne peux pas croire que cela devrait être si difficile à brancher dans TFS (c'était un morceau de gâteau dans Sourceafe, accurev et perforce, alors pourquoi si douloureux dans TFS ?).
Comment tous les autres organisent-ils leurs branches TFS? Comment changez-vous des développeurs entre branches? Comment changez-vous des constructions de serveur entre les succursales? Faut-il vraiment être aussi douloureux?
Comme indiqué dans l'autre réponse, j'ai trouvé une solution de contournement qui était acceptable pour une branche de fonctionnalité de courte durée, mais cela ne fonctionnait vraiment pas très bien. Depuis, j'ai revenu au problème et la solution complète est ridiculement simple:
Dans le Tfsbuild.Proj, le chemin était basé sur $ (BuildProjectFolderDerpath). Ce chemin résout à un côté serveur (chemin de contrôle de source) comme $ / MAIN - pas un chemin local (D: \ ServerBuildFolder \ Main).
Malheureusement, pour des raisons historiques, notre code source est divisé sur plusieurs projets d'équipe, ce qui signifie que la seule "branche" est fragmentée en plusieurs dossiers ramifiés dans la commande source (c.-à-d. $ / code / code et $ / code / code. Vous pouvez. 'T Créer une succursale contenant $ / Main et $ / Bibliothèques). Nous devons donc réassembler ces fragments disparates du contrôle de la source dans une hiérarchie cohérente à l'aide de mappages d'espace de travail.
Cela signifie que Richard était sur place - le chemin relatif du fichier TFSBUILD.PROJ au fichier .SLN était incorrect, car Msbuild / TFS suppose que le fichier .SLN réside dans le même projet d'équipe et la même hiérarchie de contrôle de la source (SO cherchait $ / Main / Bibliothèques.sln au lieu de $ / bibliothèques / bibliothèques.sln).
La solution est simple: j'ai remplacé $ (BuildProjectFolderPathe) avec un chemin local (par exemple, D: \ ServerBuildDolder \ Main) pour les fichiers, de sorte que la référence relative a été résolue dans "Espace local" (une fois que les mappages ont été appliqués ), et Msbuild fonctionne maintenant gentiment.
la morale de l'histoire:
1) N'utilisez jamais plus d'un projet d'équipe s'il y a une chance que vous souhaitiez jamais avoir une sorte de référence entre ces bases de code. Ne vous laissez pas tromper en pensant qu'un nouveau projet d'équipe offrira une sorte de distinction logique sans douleur entre applications / bibliothèques. Les projets supplémentaires se sont révélés simplement être un cauchemar d'administration - des charges de problèmes supplémentaires pour une prestation absolument nulle. (C'est tout une grande pile partagée sous le capot, de sorte que tous les postes de travail et les dossiers de contrôle de la source sont toujours visibles dans tous les projets (!), Mais il ajoute quelques murs de briques qui font des liens inter-projets très problématiques)
2) Créez toujours un seul dossier de niveau de racine dans le contrôle de la source de votre équipe de votre équipe, puis mettez tout le reste sur ce dossier. par exemple. Pour le projet "$ / main", créer "$ / main / root", puis tout mettre de la hiérarchie source à l'intérieur de la racine.
En suivant ces règles, vous pourrez brancher le dossier unique «racine» à l'avenir et vous aurez alors besoin d'une seule branche et d'une seule cartographie d'espace de travail supplémentaire. Cela vous aidera à éviter une calvitie prématurée.
(Dans ma défense, je l'aurais fait de cette façon de commencer - je travaille avec une configuration héritée. En défense de la configuration héritée, cela sonne bien sur papier mais n'était tout simplement pas une approche soutenue par Microsoft !)
J'ai aussi eu ce problème lors de la gestion d'une succursale à TFS 2010. TFS a signalé que "il n'y a pas de mappage de dossier de travail pour $ / main / produit.sln" La solution s'est avérée pour éditer la définition de construction Comme suit (j'utilise le modèle de processus de construction "modèle par défaut", je n'ai pas essayé ceci avec un modèle personnalisé):
Cela m'a aidé! Merci d'avoir sauvé la journée!
J'ai eu cette erreur et tout ce que je peux comprendre, c'est que la définition est devenue corrompue ou quelque chose. Je viens de refaire le processus de processus (ré-ajouté la solution que j'essayais de construire) et de remodeler les espaces de travail et cela a commencé à travailler à nouveau. Htth.
Lorsque vous modifiez la définition de construction, deux endroits doivent être modifiés.
J'espère que cela vous aidera.