Discussion :

[BasicZX81]

Bonsoir à tous,
Je me permets de poser la question ici car je n'ai pas obtenu de réponse dans la section "Visual Studio" du forum.

Les opérations que je souhaite faire sont simple et pourtant je suis complètement perdu avec cet outil qui est nouveau pour moi, j'avais l'habitude d'utiliser svn avant pour enregistrer les différentes révisions de mon code.
Comment faire la même chose que je faisais avant sur svn ? A savoir :

1: Dés que j'ai fini d'apporter les modifications à mon code je consulte svn pour obtenir le dernier numéro de révision utilisé.
2: Puis je mets à jour le Chanlog de mon programme avec le numéro de révision n+1 obtenu. (Je précise que je suis tout seul à travailler sur mon code donc les numéros se suivent, je n'ai jamais de surprise).
3: Une fois que j'ai changer le Changelog, j'upload les modifications sur le serveur svn, et voilà c'est fini....

Avec Team Explorer, je ne sais pas du tout comment procéder de la sorte, je vois des numéros "ensembles de modifications" qui ne semblent pas correspondre à un numéro de version.....comment obtenir ces fameux numéros de révision, comment les consulter, comment sont t'ils incrémentés......etc....

Bref, je suis complètement perdu et je vous remercie beaucoup si vous pouvez m'aider.....

[DotNetMatt]

Les terminologies sont différentes. Première question, utilises-tu TFS (Team Foundation Server, on-premises) ou bien TFS (Team Foundation Services, la version cloud, aussi appelée Visual Studio Online) ? En quelle version ?

Ce qui est commun, c'est que quand tu commit ton code on appelle ca un Change Set (ensemble de modifications en Francais). Chaque Change Set a un numéro incrémenté automatiquement lors du commit (incrément de +1).

Pour les consulter tu peux aller sur le portail web, dans ton projet, ensuite tu peux retrouver l'historique des change set et voir le code qui a été archivé dans l'onglet Code. Tu peux aussi comparer les versions, commenter, etc.

C'est ce que tu cherches ?

[BasicZX81]

Merci de me répondre DotNetMatt,

Les terminologies sont différentes. Première question, utilises-tu TFS (Team Foundation Server, on-premises) ou bien TFS (Team Foundation Services, la version cloud, aussi appelée Visual Studio Online) ? En quelle version ?

Alors en fait, je ne sais pas faire la différence. Je suppose que j'utilise Team Foundation Services puisque j'ai ce message qui s'affiche dans la fenêtre de sortie : Impossible de compléter automatiquement vos comptes Team Foundation Service. Et ce que je voulais faire au départ c'est de me débarrasser d'outils tiers comme
TortoiseSVN et de mon Serveur SVN perso au profit de l'utilisation des outils intégrés à Visual Studio Ultimate 2013 et avec les avantages du Cloud.
La version de Team Foundation Services ? Ben je ne la connais pas, mon compte s'est crée en 2 cliques à partir de VS et d'un compte xxxx@live.fr.
A chaque fois que je veux ajouter une solution au controle de code source, VS me propose : Contrôle de version Team Foundation ou Git. Je choisi à chaque fois le 1er puisque c'est celui par défaut et que j'ai encore moins compris le fonctionnement de Git.

Ce qui est commun, c'est que quand tu commit ton code on appelle ça un Change Set (ensemble de modifications en Francais). Chaque Change Set a un numéro incrémenté automatiquement lors du commit (incrément de +1).

Oui, j'ai vu ça (les ensembles de modifications). J'ai déjà plein "Change Set" sur différents "différentes solutions" contenus dans différents "projets d'équipes". Ce qui me perturbe c'est que ce numéro semble s'incrémenter non pas à partir des Commit effectués sur une solution mais aussi à partir des Commit effectués sur d'autres solutions voir même d'autres projets d'équipes. Je me trompe peut-être mais au vue du fonctionnement de cet incrément je me dit que ce n'est pas ce numéro là qui m'interresse.
Ex: Je voudrais un numéro de version qui évolue indépendamment sur chaque solution, Cela fonctionnait comme ça sur SVN, c'est possible de faire la même chose ?. (A moins que je ne comprenne pas la notion de projets d'équipe contenant plusieurs solutions auquel cas je veux bien une explication).

Pour les consulter tu peux aller sur le portail web, dans ton projet, ensuite tu peux retrouver l'historique des change set et voir le code qui a été archivé dans l'onglet Code. Tu peux aussi comparer les versions, commenter, etc.

Sauf si je suis obligé pour certaines opérations plus avancées, je passerais sur le portail Web mais on doit pouvoir faire des commits et consulter l'historique des versions depuis Team Explorer de Visual Studio non ? En tous cas je ne voudrais faire que des opérations simple que j'ai cité à partir de Team Explorer pour l'instant (si c'est possible).

C'est ce que tu cherches ?

Presque

EDIT : Bon, apriori j'utilise Team Foundation Serveur (mais sans certitude).
Je me pose des questions aussi sur le mappage correcte des dossiers, ça fait partie d'une mauvaise compréhension de ma part et qui amène des interrogations :
http://www.developpez.net/forums/d15...mplacement-tf/

[DotNetMatt]

Alors en fait, je ne sais pas faire la différence. Je suppose que j'utilise Team Foundation Services puisque j'ai ce message qui s'affiche dans la fenêtre de sortie : Impossible de compléter automatiquement vos comptes Team Foundation Service. Et ce que je voulais faire au départ c'est de me débarrasser d'outils tiers comme
TortoiseSVN et de mon Serveur SVN perso au profit de l'utilisation des outils intégrés à Visual Studio Ultimate 2013 et avec les avantages du Cloud.
La version de Team Foundation Services ? Ben je ne la connais pas, mon compte s'est crée en 2 cliques à partir de VS et d'un compte xxxx@live.fr.
A chaque fois que je veux ajouter une solution au controle de code source, VS me propose : Contrôle de version Team Foundation ou Git. Je choisi à chaque fois le 1er puisque c'est celui par défaut et que j'ai encore moins compris le fonctionnement de Git.

En effet ca a l'air d'être la version online. Pour en etre sûr, tu peux regarder l'URL que tu utilises pour te connecter à ton serveur. Si elle se termine par "visualstudio.com" c'est bien cela. Pour info c'est actuellement en version 2013.

Oui, j'ai vu ça (les ensembles de modifications). J'ai déjà plein "Change Set" sur différents "différentes solutions" contenus dans différents "projets d'équipes". Ce qui me perturbe c'est que ce numéro semble s'incrémenter non pas à partir des Commit effectués sur une solution mais aussi à partir des Commit effectués sur d'autres solutions voir même d'autres projets d'équipes. Je me trompe peut-être mais au vue du fonctionnement de cet incrément je me dit que ce n'est pas ce numéro là qui m'interresse.
Ex: Je voudrais un numéro de version qui évolue indépendamment sur chaque solution, Cela fonctionnait comme ça sur SVN, c'est possible de faire la même chose ?. (A moins que je ne comprenne pas la notion de projets d'équipe contenant plusieurs solutions auquel cas je veux bien une explication).

En effet ce n'est pas fait pour cela. La gestion des numéros de version n'est pas gérée par le gestionnaire de codes sources mais par le contrôleur de build. Le Change Set c'est juste équivalent à un commit. Il y a un numéro attribué pour pouvoir retrouver et identifier chaque commit et non pour identifier les versions (car on peut avoir des milliers de commit pour une seule évolution de version). A chaque build le numéro est incrémenté (quand le code source est complié par le serveur de build). TFS intègre nativement un tel gestionnaire basé sur MSBuild. A toi de voir si tu veux l'utiliser ou non Si non, tu dois trouver une autre facon de faire cela, et google fourmille de possibilités... Tu peux chercher "vb.net version number auto increment". Je t'invite à te documenter sur l'ALM (Application Lifecycle Management) car il faut au moins en connaitre les bases pour pouvoir l'utiliser correctement Il y a un monde entre SVN et TFS, même si les notions sous-jacentes sont les mêmes. Tu peux déjà commencer par les ALM Rangers.

Sauf si je suis obligé pour certaines opérations plus avancées, je passerais sur le portail Web mais on doit pouvoir faire des commits et consulter l'historique des versions depuis Team Explorer de Visual Studio non ? En tous cas je ne voudrais faire que des opérations simple que j'ai cité à partir de Team Explorer pour l'instant (si c'est possible).

On peut faire beaucoup de choses avec Team Explorer, mais pas tout. Et Team Explorer va te rediriger vers le portail web pour consulter par exemple l'historique des change sets. Ce que tu peux faire dans VS, c'est faire un click droit sur un fichier puis aller dans Source Control > View History (désolé je n'ai pas VS en Francais). Ensuite tu peux retrouver les infos sur ce change set en faisant un click droit sur celui qui t'intéresse puis aller dans Change set details. Mais bon ce n'est pas aussi ergonomique que par le portail web donc à toi de voir.

[BasicZX81]

En effet ca a l'air d'être la version online. Pour en etre sûr, tu peux regarder l'URL que tu utilises pour te connecter à ton serveur. Si elle se termine par "visualstudio.com" c'est bien cela. Pour info c'est actuellement en version 2013.

Ça se termine bien par visualstudio.com

En effet ce n'est pas fait pour cela. La gestion des numéros de version n'est pas gérée par le gestionnaire de codes sources mais par le contrôleur de build. Le Change Set c'est juste équivalent à un commit. Il y a un numéro attribué pour pouvoir retrouver et identifier chaque commit et non pour identifier les versions (car on peut avoir des milliers de commit pour une seule évolution de version). A chaque build le numéro est incrémenté (quand le code source est complié par le serveur de build). TFS intègre nativement un tel gestionnaire basé sur MSBuild. A toi de voir si tu veux l'utiliser ou non Si non, tu dois trouver une autre facon de faire cela, et google fourmille de possibilités... Tu peux chercher "vb.net version number auto increment". Je t'invite à te documenter sur l'ALM (Application Lifecycle Management) car il faut au moins en connaitre les bases pour pouvoir l'utiliser correctement Il y a un monde entre SVN et TFS, même si les notions sous-jacentes sont les mêmes. Tu peux déjà commencer par les ALM Rangers.

Merci beaucoup pour ces renseignements, j'ai pu investiguer un peu plus et, j'avoue que je suis encore un peu noyé....
- On a d'un coté des numéros de ChangeSet qui s’incrémentent après un commit sur des changements en attente qui couvrent l'ensemble des projets d'équipe (pas forcement lié aux projets qui me concerne....)
- On a des numéros de Build dont on peux définir le format. Le format par défaut étant : $(BuildDefinitionName)_$(Date:yyyyMMdd)$(Rev:.r)
- On a le format de type a.b.c.d (a pour version majeur, b pour version mineur, c pour build, et d pour révision) à renseigner dans la fenêtre Propriété du Projet/Application/Version de l'assembly... . On peux retrouver ces mêmes numéros dans les propriétés des fichiers exe une fois compilé. On peux aussi laisser Visual Studio incrémenter c et d à chaque génération de solution (en modifiant le fichier AssemblyInfo.vb ou cs) mais j'ai pas l'impression qu'il y a un lien avec TFS.

Voilà pour ce que j'ai vus, mais le truc c'est que j'ai l'impression que tous ces numéros vivent chacun dans leur coin sans qu'il n'y ai vraiment de rapport entre eux ou avec TFS et avec notamment la possibilité de renseigner le format de type a.b.c.d. automatiquement (ou même manuellement) à partir d'un ou plusieurs numéros obtenus depuis le serveur de contrôle de code source.

Est ce que le code $Rev:.r peux répondre à mes attentes ? Je pourrais peux être le placer dans c ou d ?

Je précise que je ne cherche pas à faire quelque chose de compliqué, juste pouvoir retrouver/consulter/restaurer un code source (placé dans le cloud) de façon relativement fiable et à partir d'un identifiant obtenu à partir des propriétés des fichiers exe (autrement dit le format a.b.c.d) même si pour cela je ne dois utiliser que la lettre d (comme je faisais avant par exemple). Comment faire cela ? Même si je doit le mettre à la main ça ne me dérange pas (sinon le mieux serait que TFS gère tous ça pour moi). Peut-être pouvez vous me conseiller la dessus.

Je suis peut-être dans l'erreur, c'est pour ça que je m'adresse à vous et désolé pour toutes ces questions mais je suis très loin d'avoir le niveau professionnel de la plupart d'entre vous sur ce forum.

[DotNetMatt]

Voilà pour ce que j'ai vus, mais le truc c'est que j'ai l'impression que tous ces numéros vivent chacun dans leur coin sans qu'il n'y ai vraiment de rapport entre eux ou avec TFS et avec notamment la possibilité de renseigner le format de type a.b.c.d. automatiquement (ou même manuellement) à partir d'un ou plusieurs numéros obtenus depuis le serveur de contrôle de code source.

Tu as tout compris, le versionning étant propre à chaque projet, il n'existe aucune règle. C'est à toi et à toi seul de créer tes règles et on ne peut pas le faire à ta place car on ne connait pas ton budget, tes ressources, l'architecture générale, le besoin final précis, etc. (c'est pour cela qu'on ne peut malheureusement pas t'aider beaucoup plus). C'est un peu comme en architecture : il y a des bonnes pratiques mais ensuite tout est possible et il existe une infinité de combinaisons possibles.

Je précise que je ne cherche pas à faire quelque chose de compliqué, juste pouvoir retrouver/consulter/restaurer un code source (placé dans le cloud) de façon relativement fiable et à partir d'un identifiant obtenu à partir des propriétés des fichiers exe (autrement dit le format a.b.c.d) même si pour cela je ne dois utiliser que la lettre d (comme je faisais avant par exemple). Comment faire cela ? Même si je doit le mettre à la main ça ne me dérange pas (sinon le mieux serait que TFS gère tous ça pour moi). Peut-être pouvez vous me conseiller la dessus.

Encore une fois difficile de t'aider précisément... Tu dois d'abord décider si tu veux utiliser le serveur de build de TFS ou si les build de Visual Studio te suffisent. Ensuite tu pourras déjà décider si tu dois t'intéresser en profondeur à MSBuild et à comment est-ce que TFS génère les livrables, ou si tu dois juste t'intéresser à la manière de gérer cela dans Visual Studio.

Ce qui est sûr c'est que tu ne dois pas te baser sur le numéro du Change Set. Après tu peux aussi avoir une table SQL ou un fichier XML qui fait référence à ce numéro, mais comme on ne connait rien à ton projet ce sont peut-être de mauvaises pistes. Et en ce qui concerne l'ALM il ne suffit pas de passer quelques heures pour avoir les clés en main. Le mieux c'est de faire des tests et de voir ce qui te convient le mieux. On pourra mieux te guider sur des questions plus précises.

Je suis peut-être dans l'erreur, c'est pour ça que je m'adresse à vous et désolé pour toutes ces questions mais je suis très loin d'avoir le niveau professionnel de la plupart d'entre vous sur ce forum.

Pas d'inquiétude à avoir, le forum est fait pour cela