% cd ~/wd/project-tree
% tla replay
[....]

Un update supplémentaire

Supposons que nous avons récupéré une vieille version de hello-world :

% cd ~/wd
% tla get hello-world--mainline--0.1--patch-1 hw-patch-1
[...]

Il est facile de voir que l'arborescence n'est pas à jour :

% cd hw-patch-1
% tla missing
patch-2
patch-3

Maintenant supposons que nous ayons fait quelques changements dans hw-patch-1 et ensuite update. Que se passe-t-il ?

Les changements locaux sont calculés par rapport au patch-1.

En d'autres termes un changeset est créé et correspond aux changements apportés à la copie originale de la révision patch-1 pour obtenir l'arborescence actuelle (hw-patch-1).

Une copie du patch-3 est récupérée.

update démarre avec la copie originale de la révision patch-3.

Le changeset est appliqué sur l'arborescence du patch-3.

Les changements calculés en premier lieu sont appliqués à cette nouvelle arborescence.

Il y a cependant une autre méthode possible :

La commande replay

Nous avons une copie du patch-1, avec éventuellement quelques changements :

% cd hw-patch-1
% tla missing
patch-2
patch-3

Souvenons-nous que les révisions patch-2 et patch-3 correspondent chacune à un changeset spécifique, stocké dans l'archive (voir « Comment ça marche ? -- commit enregistre une nouvelle révision »)

Nous pourrions effectuer les changements à notre arborescence locale en utilisant get-changeset pour récupérer chaque changeset, et utiliser dopatch pour les appliquer (voir : « get-changeset récupère un changeset d'une archive »). C'est un travail assez pénible, alors que arch fournit une solution automatique pour accomplir la même chose :

% cd ~/wd/hw-patch-1
% tla replay
[....]
% tla missing
[no output]

replay va faire exactement ce que nous avons décrit : récupérer les « patchs » de l'archive et les appliquer un par un. Un mot cependant : si un de ces patchs engendre des conflits, replay va s'arrêter là et vous laisser corriger les conflits. Vous pourrez alors reprendre où replay s'était arrêté en relançant replay une seconde fois.

Comment ça marche ? -- replay

Si vous avez suivi tout le tutoriel jusqu'ici, le fonctionnement de replay devrait être tout simplement évident. En fait, c'est exactement comme nous l'avons décrit au dessus. replay utilise missing pour trouver quels sont les changements manquants à votre arborescence, get-changeset pour récupérer ces changesets, et dopatch pour les appliquer. Il y a pas mal « d'écritures » à effectuer pour faire ça -- et ces « écritures » sont automatiquement effectuées pour vous par replay.

Version du 28/05/2004 11h55 : wilk@flibuste.net--libre   docs-tla--fr--1.0     patch-97 ... base-0