Branches élémentaires -- Gérer les changements privés
Dans ce chapitre, nous allons commencer à explorer le concept de
branche auquel vous êtes peut-être habitué avec d'autres
gestionnaire de révisions.
Si vous êtes déjà familiarisé avec ce concept, soyez conscient que le
système de branche dans arch va certainement beaucoup plus
loin que ce à quoi vous êtes habitué.
Que vous soyez ou non familiarisé avec ce concept, n'ayez crainte --
nous allons démarrer doucement.
Supposons pour le moment que le projet hello-world diffuse ses
sources au public, sur un miroir en lecture seule (voir « Archives
privées et publiques »).
Précédemment, vous (une personne extérieure au projet hello-world)
décidez que vous voulez utiliser leur programme, mais que vous avez
besoin d'y apporter quelques modifications localement.
Comme exemple ludique, supposons que vous ayez décidé que dans votre
environnement, dire « hello world » n'est pas acceptable -- vous avez
réellement besoin d'une ponctuation correcte « hello, world ».
Maintenant, voici le problème : bien sûr, vous pouvez télécharger
leurs sources et effectuer cette modification. Mais pendant ce temps,
le projet continue. Ils continuent d'effectuer des changements. Vous
serez donc perpétuellement dans l'obligation de télécharger les
sources les plus récents et d'y appliquer vos modifications.
Ce chapitre va expliquer comment arch vous aidera à automatiser cette
tache.
Dans l'exemple qui suit, vous aller changer de rôle. À la place de
« jouer » Alice et Bob, les programmeurs du projet hello-world,
vous aller « jouer » le rôle de Candice : une troisième personne.
Commençons par donner à Candice sa propre archive, et en faire son
archive par défaut :
% tla make-archive candice@candice.net--2003-candice \
~/{archives}/2003-candice
% tla my-default-archive candice@candice.net--2003-candice
default archive set (candice@candice.net--2003-candice)
(Vous pouvez voir ce que ces commandes font en lisant « Création d'une
nouvelle archive ».)
Candice a besoin de créer un projet hello-world dans sa propre
archive. Elle peut utiliser :
% tla archive-setup hello-world--candice--0.1
Elle n'a pas besoin d'utiliser le même nom de projet qu'Alice et
Bob, en fait, dans notre cas elle choisit un non de branche
différent. (Pour revoir ces commandes, voir « Création d'un nouveau
projet ».)
Quand Alice et Bob créaient leurs archive, ils utilisaient import
pour créer la première révision. Vu que nous allons créer une
branche, nous allons utiliser une commande différente:
% tla tag \
lord@emf.net--2003-example/hello-world--mainline--0.1--patch-1 \
hello-world--candice--0.1
[....]
Certaines choses méritent d'être notées à propos de cette commande.
Premièrement, notez que nous utilisons un nom de révision complet
pour se référer à la révision patch-1 d'Alice et Bob. Du fait que
cette révision ne se trouve pas dans l'archive par défaut. (voir
« Travailler avec plusieurs archives en même temps ».)
Notez que nous avons spécifié explicitement patch-1 comme
révision. Si nous n'avions pas indiqué le suffixe patch-1, la
commande tag aurait déduit que nous voulions la dernière révision de
l'archive d'Alice et Bob (qui se trouve être le patch-3).
Après avoir utilisé tag, Candice a maintenant une nouvelle
révision dans son archive :
% tla revisions --summary hello-world--candice--0.1
base-0
tag of lord@emf.net--2003-example/hello-world--mainline--0.1--patch-1
Elle peut récupérer cette révision de la manière habituelle :
% tla get hello-world--candice--0.1 hw-candice
[...]
% ls hw-candice
hw.c main.c {arch}
Friandise de arch
Si vous avez bien suivi, vous remarquerez que Candice a créé une
branche dans son archive à partir d'une révision stockée dans une
autre archive. Dans notre exemple, il se trouve que toutes ces
archives sont sur le même système de fichier mais ce n'est pas
indispensable : Candice aurait très bien pu créer sa branche même
si elle devait accéder à celle d'Alice et Bob à travers le réseau.
Candice a utilisé tag pour créer une branche à partir de
l'archive d'Alice et Bob. Dans ce cas, arch a créé ce que l'on
appelle une révision en cache de la révision base-0 du dépôt
de Candice (qui, ayant été créée avec tag, est identique à
lord@emf.net--2003-example/hello-world--mainline--0.1--patch-1.)
C'est le fonctionnement par défaut de tla à présent; cependant
l'ancien comportement (pas de mise en cache des révisions)
peut être reproduit en spécifiant l'option --no-cacherev de tla
tag.
Que ce serait-il passé sans la mise en cache de la révision ?
Lorsque Candice a utilisé get pour récupérer cette révision,
arch a pris en compte le fait qu'il s'agissait d'une branche,
et donc -- en l'absence de cachedrev -- il serait allé chercher les
sources dans l'archive d'Alice et Bob.
la question apparaît : que ce serait-il passé si l'archive d'Alice et
Bob « n'était plus » ? En l'occurrence, ce qui se serait passé, c'est
que Candice n'aurait pas pu faire de get de sa branche.
Elle aurait pu s'en sortir, à la main en mettant en cache dans son
archive toutes les informations nécessaires pour construire sa
révision, c'est à dire un cachedrev :
% tla cacherev hello-world--candice--0.1--base-0
[...]
et confirmer que ça a marché avec :
% tla cachedrevs hello-world--candice--0.1
hello-world--candice--0.1--base-0
Ainsi, arch n'aurait plus besoin de compter sur l'archive
d'Alice et Bob pour récupérer la révision base-0.
Précédemment, Candice créait sa branche et utilisait get pour
la récupérer. Examinons cette arborescence :
% cd ~/wd/hw-candice
% tla log-versions
candice@candice.net--2003-candice/hello-world--candice--0.1
lord@emf.net--2003-example/hello-world--mainline--0.1
Notez que l'arborescence de Candice contient à la fois les logs de
patchs des version d'Alice et Bobs, et à la fois ceux de sa propre
branche :
% tla logs --summary \
lord@emf.net--2003-example/hello-world--mainline--0.1
base-0
initial import
patch-1
Fix bugs in the "hello world" string
% tla logs --summary hello-world--candice--0.1
base-0
tag of \
lord@emf.net--2003-example/hello-world--mainline--0.1--patch-1
Il n'y a plus de changements sur la branche de Candice :
% tla missing hello-world--candice--0.1
[no output]
mais souvenez vous qu'Alice et Bob en sont déjà au patch-3 :
% tla missing -A lord@emf.net--2003-example \
hello-world--mainline--0.1
patch-2
patch-3
Après le tag initial, Candice peut archiver les changements de sa
branche avec la méthode habituelle.
Supposons maintenant qu'elle ait modifié hw.c qui contient donc en
partie :
% cat hw.c
[...]
void
hello_world (void)
{
(void)printf ("hello, world\n");
}
[...]
et qu'elle a préparé un message de log :
% cat ++log.hello-world--candice--0.1--lord@emf.net--2003-candice
Summary: Punctuated the output correctly
Keywords:
This program should say "hello, world" not "hello world".
Maintenant elle peut archiver de la manière habituelle, en créant sa
propre révision patch-1 :
% tla commit
[....]
% tla revisions --summary hello-world--candice--0.1
base-0
tag of \
lord@emf.net--2003-example/hello-world--mainline--0.1--patch-1
patch-1
Punctuated the output correctly
Entre temps, Alice et Bob ont créé leurs révisions patch-2 et
patch-3. Comment Candice peut-elle appliquer ces changements à sa
branche ?
À ce niveau, arch fournit réellement beaucoup de techniques. En
utilisant les commandes précédemment étudiées, elle pourrait utiliser
soit update soit replay. Dans cet exemple, nous allons montrer
l'utilisation de replay.
% cd ~/wd/hw-candice
% tla replay -A lord@emf.net--2003-example \
hello-world--mainline--0.1
[...]
Notez que nous avons utilisé l'argument -A pour indiquer de quelle
archive nous allons récupérer les changements, et le nom de la version
pour indiquer quels changements nous voulons. Dans ce cas, replay
appliquera les changesets de patch-2 et patch-3 à l'arborescence
de Candice.
Cette utilisation de replay est une forme de « fusion » (merging) : Les
changements locaux de Candice ont été fusionnés avec les changements
d'Alice et Bob sur leur mainline.
Note
Si vous avez suivi les exemples, vous devriez examiner
hw.c et
noter que les changements de Candice sur la chaîne de
printf et
l'ajout de la notice
copywrong sont toutes les deux incluses.
Note
Vous devriez également récupérer une deuxième copie de la révision
patch-1 et expérimenter en effectuant la même fusion en
utilisant
update au lieu
replay. Vous devriez regarder
tla update -help et voir ainsi quelles sont les options et
arguments adéquats.
Notez également que, jusqu'à présent, nous avons seulement appliqué
les changements sur l'arborescence du projet de Candice -- ceux-ci
n'ont pas été enregistrés dans l'archive de Candice. Pour enregistrer
la fusion dans son archive, elle devra créer un message de log et
archiver par la méthode habituelle (voir « Archiver les changements »).
Il y a, cependant, encore une convenance à respecter. Quand Candice
écrit son message de log, elle voudra vraisemblablement noter qu'il y
a eu une fusion et ce qu'elle a entraîné. Arch comporte une commande
dont la sortie est idéale pour ce message de log :
% cd ~/wd/hw-candice
% tla log-for-merge
Patches applied:
* lord@emf.net--2003-example/hello-world--mainline--0.1--patch-3
added copywrong statements
* lord@emf.net--2003-example/hello-world--mainline--0.1--patch-2
commented return from main
Impression