Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

Noham Choulant

Toutes les informations sur VSTS

Actualités

venez donnez votre avis
Est-il, pour vous, important de pouvoir gérer une version locale de l'historique des modifications d'un projet et de pouvoir synchroniser sur un TFS pour l'ensemble de l'équipe ? Est-il pertinent de pouvoir se synchroniser entre développeur sans polluer TFS ? lien : http://choulant.blogspot.com/2010/09/tfs-et-ma-gestion-local.html
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
Posted: jeudi 9 septembre 2010 22:43 par pc152
Classé sous :

Commentaires

KooKiz a dit :

http://msdn.microsoft.com/en-us/library/ms181283(VS.80).aspx

# septembre 9, 2010 23:15

pc152 a dit :

KooKiz, la réservation de TFS ne permet pas de :

Gérer un historique en local

D'envoyer des modifications par mail

De partager avec un ou plusieurs un ensemble de modification avec historique

La réservation de TFS permet certaine chose mais à un niveau simple d'utilisation.

# septembre 9, 2010 23:22

pc152 a dit :

http://4.bp.blogspot.com/_LAIjcLI8YYc/TIlFL4CpzCI/AAAAAAAABQY/ZtyVPzRejNQ/s1600/Schemas.png

# septembre 9, 2010 23:30

Kangoo a dit :

Pour moi, ce dont tu parles ici est ni plus ni moins qu'une branche au sein d'une stratégie de branche :

Tu as de l'historique et tu partages avec un ou plusieurs personnes sans polluer les dev principaux...

# septembre 10, 2010 09:16

pc152 a dit :

Attention, je ne parle pas de stratégie de branche, je parle de stratégie de codesource. @Kangoo, je comprends bien, mais si j'ai 10 développeurs je ne vais certainement pas polluer mon TFS avec 10 branches de développement.

Le débat est intéressant, ma vision est vraiment différente et je pense vraiment faire un article sur ce sujet.

Il existe déjà ce type de concept utilisé depuis 5 ans. Je pense que TFS est un bon outil mais dans une utilisation courante il lui manque certaine fonctionnalité. Je sais que MS va intégrer (des petits bruits de couloir) une version décentralisé dans la prochaine version. Cela rejoint donc ma réflexion.

# septembre 10, 2010 09:29

Kangoo a dit :

C'est quoi pour toi la différence entre stratégie de branche et stratégie de code source (première fois que j'entends ce terme) sachant qu'une stratégie de branche... concerne le code source... ?

Concernant les branches de dev, j'ai plusieurs clients qui, sur des projets spécifiques, ont plusieurs branches de développement. Ca fonctionne bien et tous les cas que tu cites peuvent entrer dans ce mode de fonctionnement.

Enfin, il ne faut pas confondre version décentralisée/distribuée avec le fait d'être déconnecté du source control.

Dans quel autre produit le concept dont tu parles existe-t-il déjà ?

# septembre 10, 2010 09:44

pc152 a dit :

Pour moi une stratégie de code source ne concerne que le code source et rien d'autre. Une stratégie de branche concerne effectivement le code source, mais également la gestion des versions, des path correctif, des builds, des tests etc... C’est une stratégie englobant beaucoup de chose. Elle met aussi à contribution des équipes de développement, de testeurs, d’intégrateur et les équipes clients.

Moi je parle de reste au niveau des développeurs et donc du code source, oui il y a les réservations mais qui ont leur limite. Je ne parle pas non plus de déconnection. Le mode déconnection ne permet pas d'avoir un historique et donc de revenir en arrière, revenir à une date ou un label précis.

Personnellement je trouve important de pouvoir avoir son propre historique en local permettant de tester des développements, des architectures de les partager avec d'autre membre de l'équipe.

Chez mes clients je préconise le minimum de branche pour un maximum de maintenabilité, de stabilité. Les branches oui mais pas de foret.

# septembre 10, 2010 10:34

Etienne Margraff a dit :

Personnellement, je trouve ça très curieux de stocker un historique localement.

Je me rappele que Mathieu (http://batswirl.com/blogs/batswirl_fr/) avait un jour développé un outil qui effectue un shelve toutes les X minutes tournant sur un nombre défini par le développeur.

Evidemment cette solution ne permet pas d'effectuer de comparaison ou je ne sais quoi d'autre, mais je trouve que c'est largement suffisant pour le besoin.

Mais bon, c'est que mon humble avis :)

# septembre 10, 2010 20:03
Les commentaires anonymes sont désactivés
Les 10 derniers blogs postés

- Etendre le Team Web Access de TFS 2012 – Step 0 par Philippe Didiergeorges Aka Philess le il y a 6 heures et 38 minutes

- Simuler facilement l’envoi de mail par Blog de Jérémy Jeanson le 05-22-2013, 12:52

- ProcDump 6.0 : support du filtrage sur messages d'exceptions .NET, des filtres multiples et du ciblage par nom de service par CoqBlog le 05-20-2013, 14:50

- Votez pour le TOP 10 des influenceurs SharePoint francophones ! par Le blog de Patrick [MVP SharePoint] le 05-20-2013, 12:59

- [Conf’SharePoint] Dernier rappel ! :-) par Le blog de Patrick [MVP SharePoint] le 05-20-2013, 09:09

- [ #SharePoint 2013 ] les modèles de sites standards… par Le blog de Patrick [MVP SharePoint] le 05-20-2013, 09:03

- 10 erreurs de compréhension concernant SharePoint… par Le blog de Patrick [MVP SharePoint] le 05-20-2013, 08:27

- Conf’SharePoint : 10 bonnes raisons pour ne pas la rater par Le petit blog de Pierre / Pierre's little blog le 05-14-2013, 02:24

- [Event] Soirée de lancement Agile .NET France à Lyon par Blog Agile/ALM de Vincent THAVONEKHAM le 05-13-2013, 01:29

- .NET / Debug : inspection de la mémoire d'applications .NET (dump ou processus live) : première livraison d'une librairie .NET par Microsoft par CoqBlog le 05-11-2013, 22:21