none
considérations générales sur le controle de code source avec TFS RRS feed

  • Question

  • Bonjour,

    Après avoir installé TFS. je suis actuellement en train d'ajouter différents projets au controle de code source. C'est la que les problèmes commencent à apparaitre, prennons un exemple :

    Imanginez une arborescence de repertoires structurés comme suit :

    Projets

      +Outils communs

      +Projet 1

      +Projet 2

     

    Projet 1 et Projet 2 référencent et utilisent des fichiers qui se trouvent dans Outils communs. Quand j'ajoute Projet 1 au controle de code source celui-ci ne peut pas prendre en compte les fichiers contenus dans Outils communs car ils ne sont pas dans l'arborescence fille de Projet 1.

    Il s'agit la d'une fonctionnalité assez simple à prendre en compte et je ne peux pas croire qu'un outil puissance comme TFS ne sache pas répondre à ce besoin.

     

    Donc comment faire, sachant qu'il est hors de question, pour des raisons évidentes, de dupliquer Outils communs dans Projet 1 et dans Projet 2.

     

    Cordialement

    Michel4CE

    • Déplacé Shrikant Maske mercredi 19 janvier 2011 21:57 Forum consolidation (Origine :Visual Studio Team System)
    dimanche 25 novembre 2007 10:31

Réponses

  • Bonjour,

     

    Il existe 3 solutions à un tel problème.

     

    1 - Récupération des sources à l'aide des workspaces

     

    Il s'agit de récupérer les projets d'outils communs et de Projet 1 à l'aide d'un espace de travail comportant plusieurs liaisons (mapping).

     

    Ex :

     

    Server Item : $/MonProjet/Outil Communs/   Local Item : C:\WKS\Michel\Outil Communs Mapping : Active

    Server Item : $/MonProjet/Projet 1/          Local Item : C:\WKS\Michel\Projet 1 : Mapping : Active

     

    Le résultat : le dossier C:\WKS\Michel contiendra les projets de Outils communs et de projet 1.

     

    2 - Création d'une branche de Outil Commun dans un dossier de projet 1

     

    On branche Outil Communs dans un sous-dossier du dossier du projet afin de retarder les modifications effectuées par les développeurs de projet 1 sur les outils communs tout en leur mettant à disposition le code qu'il contient.

     

    3 - Team Build et référencement (solution que je préconise)

     

    Les outils communs sont buildés ( et éventuellement déployés) en continu à l'aide de Team Build et ne sont plus accessibles aux développeurs qu'à l'aide des binaires. Les modifications apportées à Outils Communs seront alors effectuées dans une solution et éventuellement un espace de travail propre.

     

    Cordialement,

     

    Mathieu Szablowski

     

     

    mardi 27 novembre 2007 22:18

Toutes les réponses

  • Bonjour,

     

    Il existe 3 solutions à un tel problème.

     

    1 - Récupération des sources à l'aide des workspaces

     

    Il s'agit de récupérer les projets d'outils communs et de Projet 1 à l'aide d'un espace de travail comportant plusieurs liaisons (mapping).

     

    Ex :

     

    Server Item : $/MonProjet/Outil Communs/   Local Item : C:\WKS\Michel\Outil Communs Mapping : Active

    Server Item : $/MonProjet/Projet 1/          Local Item : C:\WKS\Michel\Projet 1 : Mapping : Active

     

    Le résultat : le dossier C:\WKS\Michel contiendra les projets de Outils communs et de projet 1.

     

    2 - Création d'une branche de Outil Commun dans un dossier de projet 1

     

    On branche Outil Communs dans un sous-dossier du dossier du projet afin de retarder les modifications effectuées par les développeurs de projet 1 sur les outils communs tout en leur mettant à disposition le code qu'il contient.

     

    3 - Team Build et référencement (solution que je préconise)

     

    Les outils communs sont buildés ( et éventuellement déployés) en continu à l'aide de Team Build et ne sont plus accessibles aux développeurs qu'à l'aide des binaires. Les modifications apportées à Outils Communs seront alors effectuées dans une solution et éventuellement un espace de travail propre.

     

    Cordialement,

     

    Mathieu Szablowski

     

     

    mardi 27 novembre 2007 22:18
  • Bonjour,

    tout d'abord merci pour cette (ces) réponses.

    Je ne suis pas certain, cependant, de les interpréter correctement.

    Par exemple, qu'appelez vous Mapping:Active ?

    La solution qui consiste à créer un répertoire parent commun pour les deux solutions et à créer ensuite une branche sur la racine de cette arborescence ne colle réponds pas au besoin.

     

    La solution 2 n'ai pas acceptable car elle oblige à dupliquer "Outils communs" dans projet 1 et c'est justement ce que je souhaite éviter.

    Le solution 3 est séduisante mais les outils communs sont en réalité des classes qui ne sont pas compilées en tant que projet autonome. Il constitue plus un banque de code source.

     

    La solution que j'ai trouvé est la suivante :

    Dans un premier temps j'ai créé un projet VS vide dans lequel j'ai placé le code .H et .CPP de  "Outils communs". Dans un deuxème temps j'ai ajouté ce projet au controle de code source. Pour finir j'ai ajouté projet 1 au controle de code source.

    Le message d'avertissement n'apparait plus, le source control semble satisfait.

     

    Je pense que cette solution donc être assez proche de la solution 1 que vous proposez.

    J'aimerai cependant que vous apportiez quelques éclairsissements sur votre solution.

     

    Cordialement

    Michel4CE

     

     

    jeudi 29 novembre 2007 09:08
  •  

    Le solution 1 de Mathieu est la même que la votre, celle de mathieu viens après la votre. vous pouvez mapper Deux projet différent dans un seul WorkSpace. la balise Mapping:Active est une des deux possiblités de mapping dans les WorkSpace Active signifit que vous récupérer le code source, que le projet fait bien parti de votre WORKSPACE.

     

     

    lundi 10 décembre 2007 16:36