Le chapitre précédent introduisait la notion de changeset et des commandes mkpatch et dopatch (variations sur le thème des programmes traditionnels diff et patch).
Dans ce chapitre, nous allons étudier d'une manière plus détaillée comment les changesets sont utilisés dans les archives, comment ils sont utilisés par les commandes commit et update, et ce que cela peut nous apporter pour utiliser arch au mieux.
Supposons que vous ayez récupéré la dernière révision d'un projet (avec get), écrit un message de log, et archivé vos modifications (avec commit). Que s'est-il passé ?
Sachant cela, vous aurez peut-être envie de revenir en arrière et de revoir la section précédente « Comment ça marche ? -- archiver (commit) une nouvelle révision »
Nous avons appris plus tôt que la commande cat-archive-log récupérait un message de log d'une archive (voir « Étudions pourquoi Alice ne peux pas faire de commit »)
Vous pouvez aussi récupérer un changeset d'une archive.
% cd ~/wd % tla get-changeset hello-world--mainline--0.1--patch-1 patch-1 [...]
get-changeset récupère le changeset de l'archive et, dans ce cas, l'enregistre dans un répertoire appelé patch-1
(Le format des changesets est décrit dans « Le format arch d'un changeset ».)
Le format d'un changeset est optimisé pour être utilisé par des programmes, pas par des personnes. Il est difficile pour un humain d'analyser un changeset. Au lieu de ça, vous pouvez obtenir un rapport du patch au format diff en utilisant :
% tla show-changeset --diffs patch-1 [...]
Si vous avez suivi les exemples précédents, vous reconnaîtrez le format du rapport de show-changeset de la commande changes expliquée plus tôt (voir « Oh mon dieu -- Qu'ai-je fait ? »).
Lorsque vous archivez (commit) un ensemble de modifications, il est généralement « de bon usage » de s'assurer qu'il s'agit d'un changeset « propre ».
Un changeset « propre » ne doit contenir que des modifications concernant un seul dessein. Si, par exemple, vous avez plusieurs bugs à corriger, ou plusieurs fonctionnalités à ajouter, essayer de ne pas les mélanger dans un seul commit.
Relecture facile
Il est plus facile pour quelqu'un de comprendre un changeset s'il ne concerne qu'une seule chose.
Fusion facile
Comme nous le verrons dans les chapitres suivants, dans certaines circonstances, nous allons avoir besoin d'examiner une collection de changesets pour en sélectionner quelques unes. Peut-être voudrez vous récupérer la correction A mais pas la fonctionnalité B. Si un changeset n'a qu'un seul dessein, ce genre de cueillette (cherrypicking) sera plus pratique.
Version du 31/05/2004 21h18 : wilk@flibuste.net--libre docs-tla--fr--1.0 patch-99 ... base-0