Sélection des fichiers à archiver (commit)
Précédemment, vous avez appris à archiver tous les
changements d'une arborescence d'un coup (voir: « Archiver les
changements »)
Vous avez aussi lu à quel point il est important de faire des
changesets « propres » (voir: « Bien archiver (commit) -- L'idée
d'un changeset propre »)
Ce chapitre vous montre une petite astuce que vous pouvez utiliser
dans une situation bien spécifique mais assez courante.
Supposons que sur un projet conséquent vous ayez une grande
arborescence et que vous êtes en train d'effectuer des changements
complexes. Vous avez modifié de nombreux fichiers, mais il y en a
beaucoup d'autres qui n'ont pas été touchés.
Subitement, vous vous rendez compte d'un bug trivial sur un fichier
non modifié.
Ce que vous aimeriez faire c'est :
- Arrêter et réparer ce bug trivial
- Archiver cette correction triviale.
- Retourner travailler sur les changements complexes.
Comment pouvez-vous faire ?
Il y a une solution « brutale » à ce problème.
Tout simplement :
Récupérer une copie fraîche de la dernière révision
En d'autre termes créer une seconde arborescence sans vos changements.
Réparer le bug trivial dans cette nouvelle arborescence puis archiver
Maintenant vous avez archivé un changement propre avec la
correction du bug trivial uniquement.
Utilisez update ou replay pour mettre à jour votre arborescence originale
Ce qui va ajouter la correction du bug trivial à votre arborescence en
cours.
Ça fonctionne, mais c'est un petit peu exagéré. Avez-vous
réellement besoin de créer une nouvelle arborescence rien que pour
réparer ce bug trivial ?
Parfois cette exagération est méritée. Par exemple, si votre projet à
comme politique de lancer quelques tests avant chaque archivage. Dans
ce cas, oui, vous devez réellement créer une nouvelle arborescence.
Parfois cette exagération est indispensable. Par exemple, si la
réparation du bug oblige à modifier des fichiers que vous avez déjà
modifié, alors, la solution brutale sera l'approche la plus simple
(mais quand même, jetez un oeil à tla undo --help et tla redo
--help).
Mais il y a une solution plus simple qui peut parfois être utilisée :
Comme nous le verrons, commit permet de ne prendre en compte que
les changements de quelques fichiers.
Si votre correction ne modifie que les fichiers file-a.c et
file-b.c, alors après avoir préparé un message de log, vous
pourrez archiver uniquement ces fichiers :
% tla commit -- file-a.c file-b.c
Notez que les fichiers archivés de cette manière ne doivent pas être
des nouveaux fichiers, même si ces fichiers ont été renommés, le
commit ne va enregistrer que les modifications internes de ces
fichiers, pas les renommages.
Dans le texte précédent, nous avons étudié une solution « brutale » au
problème de la correction express qui impliquait de récupérer la
totalité de l'arborescence du projet.
Deux autres commandes, tla undo et tla redo, fournissent une
autre alternative « brutale » avec quelques avantages. (Essayez tla
undo --help et tla redo --help)
Version du 31/05/2004 21h18 : wilk@flibuste.net--libre docs-tla--fr--1.0 patch-99 ... base-0
Impression