[TFS]Réserver / Déreserver les modifications en attentes

[seb.49]

Bonjour,

Je cherche quelques éclairage sur la notion de "réservation" de modification dans TFS

Voici ce que j'ai fait pour tester. Soit une page de code
ETAPE 1, j'écris ceci

Code :

//VERSION LIVREE 1.0

et j'archive mon fichier.
ETAPE 2 J'extrait le code et je tape ceci

Code :

//MODIFICATION POUR LA V2 en (attente)

ETAPE 3 je fais un clic droit sur mon fichier, je choisi "Réserver les modi." et je décoche "Conserver les modif. en attente localement". Mon fichier se retrouve comme à l"tape 1. Je tape ceci

Code :

//correction sur la V1 (archivée, livrée)

et j'archive. Je déréserve alors les modification en attente. Je me retrouve avec ceci dans mon fichier

Code :

1
2
3
 
//VERSION LIVREE 1.0
//MODIFICATION POUR LA V2 en (attente)

Et c'est la que pour moi c'est pas normal, pour retrouver mon code tapé à l'étape 2, je dois faire "Récuper la dernière version" puis résoudre le conflit manuellement. J'imagine meme pas la galere pour refusionner les modifs sur un vrai projet.

Est ce que je me trompre quelque part ou c'est bien le comportement normal de TFS sur ce point.

Merci pour votre aide

[ctxnop]

Salut,
Si je comprend bien tes étapes c'est le comportement normal.

1. Tu obtiens le jeu de modifications N°123
2. Tu modifies tes sources => modifications en attentes.
3. Tu archive => jeu de modifications N°124 (y compris sur disque)
4. Tu re-modifie => modifications en attentes.
5. Tu réserves => plus de modifications en attente.
6. Tu re-modifies => modifications en attentes.
7. Tu archives => jeu de modifications N°125 (y compris sur disque)
8. Tu dé-réserve : conflit, la réservation avait été faite avec la version 124 or tu possède une version plus récente (la 125), tu dois fusionner.

L'étagère peut s'utiliser globalement de deux façons :
1) La réservation temporaire pour pouvoir archiver.
Dans certaines équipes/projet on définit des dates butoires régulière. Arrivé à échéance, une version est automatiquement générée. Les développeurs doivent y inclure la dernière avancée sur leurs travaux. Cependant, dans certains cas, si le développeur archive tout, ça ne compilera tout simplement pas, il est en plein milieu d'un gros truc.
Le plus simple est alors de réserver le code qui posera problème afin de pouvoir archiver le reste, puis de dé-réserver pour reprendre là où il s'était arrêté.

2) La réservation pré-compilation pour valider l'archivage
Quand tu archives du code il arrive souvent d'oublier un fichier ou un petit truc qui va faire que ça ne compilera pas. On peut alors définir une politique d'archivage qui consiste à interdire l'archivage directe. Les développeurs réservent les modifications et lancent une compilation automatique en incluant leurs modifications réservées. Dans la définition de la build on peut spécifier un jeu de réservation. On coche également la petite case magique juste en dessous. De cette façon, la compilation automatique se fait et si elle réussit alors les modifications réservées sont automatiquement archivée. L'avantage est que le dépôt ne peut alors pas contenir d'erreur empêchant la compilation. On peut aller plus loin en définissant des tests unitaires à lancer et du coup, n'est archivé que le code qui ne détériore pas la qualité du logiciel.

Voilà, j'espère avoir répondu à toutes tes questions.

[seb.49]

Merci pour cette réponse. J'en demandais trop à cette fonctionnalité.

Je voulais pouvoir récupérer le code correspondant à une version livrée aux clients pour la modifier (en cas de bug vraiment mineur alors que je développe d'autres fonctionnalité mais que je ne veux/peux pas les publier) puis la republier et enfin reprendre mon code avec la modification.

[Nathanael Marchand]

Quand on livre, on fait une branche. Si y'a un bug sur la version de livraison on corrige sur la branche et on réplique sur le trunk.