none
Attempt to remap RRS feed

  • Question

  • Bonjour,

    J'ajoute actuellement un gros projet sous le controle de code source et j'obtiens un message d'avertissement sur lequel je recherche des éclairssissements.

    "Attempt to remap source control folder x:\projet1\dummy Remap to : x:\projet1\projet1\dummy"

     

    J'ai la possibilité de répondre oui ou non. Je comprends bien ce qui se produira si je dis oui ou non, mais je me demande pourquoi TF veut remapper mon projet et le déplacer physiquement sur le disque local ?

     

    Dans la pratique si je répond non le source explorer tourne en boucle et m'affiche le même warning jusqu'a ce que je réponde oui.

    Une fois que j'ai répondu oui, il me faut modifier toutes les références absolues présente dans mon projet afin de pouvoir refaire un build... pas pratique. Sad

     

    Cordialement

    Michel4CE

    • Déplacé Shrikant Maske mercredi 19 janvier 2011 22:00 Forum consolidation (Origine :Visual Studio Team System)
    jeudi 29 novembre 2007 11:13

Toutes les réponses

  • Bonjour

     

    Quel est votre configuration des espace de travail ?

     

    vendredi 7 décembre 2007 12:45
  •  

    Je ne sais pas comment répondre efficacement à votre question.

    Ce projet est composé de plusieurs milliers de fichiers C/C++ qui sont réapartie en 17 projets.

    Afin de m'adapter aux contraintes qu'impose le source explorer VSTFS j'ai importé l'arborescence physique dans le source controle. Je veux dire que comme je n'ai pas pu ajouter la solution au source controle, directement, mais que j'ai mappé le répertoire sur un workspace. J'espère que vous saisissez la nuance Wink

     

    Donc tant que je reste sur le PC qui a été utilisé pour réaliser cette opération il n'y a pas de problème. Par contre quand je souhaite modifer ou tester le code sur un autre poste (un autre developpeur de l'équipe) VSTFS me reconstruit bien l'arboresence sur le PC cible mais il modifie les chemins relatifs à l'intérieur des fichiers VCProj et même du fichier sln.

    Je dois donc si je veux les réutiliser localement les modifier manuellement ou copier les fichiers depuis el PC Source...bizarre

     

    Deux explications me viennent à l'esprit :

    1. Je suis passé à côté du caractéristique du produit
    2. Il s'agit d'un bug

    Merci de m'éclairer sur ce point et de me faire partager vos remarques.

    Michel4CE

    dimanche 9 décembre 2007 08:53
  •  

    "Je veux dire que comme je n'ai pas pu ajouter la solution au source controle, directement, mais que j'ai mappé le répertoire sur un workspace. J'espère que vous saisissez la nuance"

     

    Je pense que le problème vient de là, dans une configuration normale, il suffit d'ouvrir le projet puis de l'ajouter au controlleur de code source. je n'arrive pas a comprendre comment vous avez pu mapper le le WorkSpace sans passer par l'étape d'ajout de projet. Votre problème dépasse mes compétences.

     

    Ce que je peux vous suggérer, c'est de recréer votre projet d'équipe et d'ajouter vos projets de la façon, que je nommerais, traditionnel.

     

    Cordialement

    lundi 10 décembre 2007 15:13
  • Bonjour,

    Je comprends bien votre suggestion et c'est bien entendu ce que j'ai essayé de faire en premier.

    Malheuresement VSTFS a du mal à faire ce Visual Studio fait. Je veux dire par là que VSTFS n'accepte que très difficilement qu'un projet soit réparti dans une arborescence MULTI-ANCETRE. Cette lacune m'a obligé à importer/mapper manuellement mon projet dans VSTFS. Malheuresement le problème lié à la mauvaise prise en charge des arboresences multi-ancetre devient un BUG quand on souhaite syncroniser un projet entre plusieurs poste.

     

    J'espère que MS a conscience de ce problème et que la prochaine version de VSTFS saura le corriger.

     

    Cordialement

    Michel4CE

     

    lundi 10 décembre 2007 15:42
  •  

    Bonsoir,

     

    Votre problème n'est pas un bug mais il y a tout de même une limitation de TFS et plus particulièrement de la partie Source Control concernant la création des espaces de travail et de liaison des projets et des solutions de VS dans le contrôleur de code source.

     

    Ce que je suppose toutefois de votre message, c'est l'utilisation de l'outil Change Source Control (disponible dans le menu File our fichier de VS) pour lier vos projets avec l'espace du contrôleur de code source.

     

    Je ne recommande pas l'utilisation de cet outil car : il autorise Visual Studio à créer votre Workspace et donc à créer (dans la plupart des cas) des références inutiles voire multiples (un fichier ou un dossier local apparait plusieurs fois dans les définitions de liaisons).

     

    S'il s'agit bien de votre manière de procèder, je ne saurais que trop vous conseiller de ne jamais laisser Visual Studio construire votre Workspace à votre place mais également de bien reprendre la définition de ce nouvel outil (les workspaces n'ont plus grand chose à voir avec les Working Folders de VSS par exemple) et ses contraintes qui sont particulièrement bien reprises dans la MSDN.

    La définition et la construction d'un référentiel de code source doit prendre en compte la création des workspaces des utilisateurs et notamment le référencement des différents projets par les différentes solutions.

     

    En sachant que certains concurrents offrent une plus grande souplesse dans la création des espaces de travail, je pense que les limitations actuellement vont rapidement être gommées.

     

     

    jeudi 13 décembre 2007 00:11