Eclats de vers : Ordina 08 : Contrôle de version

Supposons que nous effectuions un ensemble de modifications sur la révision P et que cela nous mène à la révision E. On dit alors que P est un parent de E ou que E est un enfant de P.

Si deux révisions A et B peuvent être reliées par une chaîne de révisions parent-enfant et que A est antérieure à B, on dit que A est un ancêtre de B.

Une branche est une variante d'un projet disposant de son propre historique de versions. Il est donc possible de gérer plusieurs branches se développant en parallèle. Chaque branche peut être issue d'une autre branche, ou de la variante originelle du projet. Autrement dit, chaque branche peut elle-même générer une autre branche, ce qui donne une structure arborescente au dépôt.

L'opération de fusion (merge en anglais) est l'opération inverse de la création de branche : elle consiste à réunir deux branches ayant un ancêtre commun en fusionnant leurs modifications depuis leur scission.

La référence à une révision peut se faire schématiquement par :

branche/numéroDeVersionDansLaBranche

Lorsqu'il existe plusieurs dépôts contenant le projet et que chacun contient des branches qui lui sont propres, on peut compléter cette référence par :

dépôt/branche/numéroDeVersionDansLaBranche

L'option -r permet de générer un fichier différentiel comparant deux répertoires :

diff -u -r /avant/ /après/ > /delta/

Pour appliquer le patch, il suffit de se rendre dans le répertoire auquel on souhaite l'appliquer, puis :

patch < /delta/

L'option -R permet d'annuler les modifications d'un patch :

patch -R < /delta/

Il est possible que le répertoire dans lequel on souhaite appliquer le patch soit différent de celui dans lequel il a été créé. Comme les chemins stockés dans le patch sont absolus, il faut parfois les raccourcir pour en faire des chemins relatifs, sans quoi le patch s'appliquera aux mauvais fichiers, voire à des fichiers qui n'existent pas. L'application d'un patch où les chemins sont raccourcis de N répertoire depuis la racine s'effectue via la commande :

patch -p/N/ < /delta/

On peut simuler l'application du patch :

patch --dry-run < /delta/

Il est possible d'inclure les modifications transformant un fichier départ en un fichier arrivée dans un autre fichier fusion :

merge /fusion/ /départ/ /arrivée/

La commande diff3 ressemble à merge, mais permet de sortir le résultat sur la sortie standard plutôt que de modifier un des fichiers :

diff -m /fusion/ /départ/ /arrivée/ > /fusionné/

Dans le cas d'une branche particulière issue de Version.Niveau, on a la notation :

Version.Niveau.Branche.NiveauDansBranche

Les révisions de la première branche de la version 2.4 s'écrivent donc :

2.4.1.1 — 2.4.1.2 — 2.4.1.3 — ...

Le shell permettant les accès à distance utilisé par cvs est le contenu de la variable d'environnement CVS_RSH. Pour utiliser ssh, on place la ligne :

export CVS_RSH=ssh

dans le zshrc, zshenv, ou autre fichier d'initialisation de votre shell. Pour un accès local, le contenu de CVSROOT est de la forme :

export CVSROOT=:local://répertoireDépôt/

où le :local: est optionnel. Pour un accès distant, on a la directive :ext: permettant d'utiliser le CVS_RSH :

export CVSROOT=:ext:/utilisateur/@/machine/://répertoireDépôt/

Commandes à effectuer dans un répertoire de travail.

Pour annuler une modification, il suffit de fusionner de la révision la plus récente à la plus ancienne :

cvs up -j /après/ -j /avant/

Pour un accès à un dépôt local, on utilise :

file:////cheminAbsolu/

Pour un accès à un dépôt distant, on utilise la communication via un tunnel ssh :

svn+ssh:///utilisateur/@/machine///chemin/

ou le serveur svn, s'il est lancé :

svn:///utilisateur/@/machine///chemin/

Au fil des révisions, il peut arriver que le même nom soit porté par des fichiers différents : on renomme ou supprime le premier et un autre apparaît à sa place par exemple. Le nom du fichier ne suffit donc plus à le caractériser, il faut également indiquer une révision de référence afin de le distinguer de ses homonymes. La notation générique est :

/fichier/@/Révision/

On retrouve également les notations :

Commandes à effectuer dans un répertoire de travail.

La validation des modifications lance un éditeur pour écrire les commentaires associés. On peut aussi écrire les commentaires au fur et à mesure, les sauver dans un fichier commentaires et valider par :

svn commit -F /commentaires/

Un commit nécessite que les fichiers modifiés sur la copie de travail soient à jour par rapport au dépôt. Par contre, nul besoin que le projet entier soit à jour.

Ces commandes s'effectuent généralement dans un répertoire de travail. Les modifications ne seront validées dans le dépôt qu'après un svn commit. On peut aussi spécifier une url protocole://dépôt/répertoire en argument. Dans ce dernier cas, les modifications sont immédiates.

Pour préciser une révision de référence R, on utilise bien entendu la notation :

svn cat -r /N/ /fichier/@/R/

Si le fichier n'existe pas dans la copie de travail actuelle, il faut recourir à l'url du dépôt :

svn cat -r /N/ /proto/:///dépôt///chemin///fichier/@/R/

L'option –depth permet de régler le nombre de niveaux de répertoires sur lesquels une action agit. Elle est infinie par défaut. Les valeurs possibles sont :

Il est possible de limiter une fusion aux modifications d'une révision :

svn merge -r /N/ /urlDépôt///répertoireDeRéférence/

ou d'une plage de révisions :

svn merge -r /M/:/N/ /urlDépôt///répertoireDeRéférence/

Il est possible de comparer deux url de références et d'appliquer les différences à la copie de travail :

svn merge /url1/ /url2/ /répertoireCopieDeTravail/

La commande merge compare les fichiers par rapport à leurs ancêtres / successeurs dans l'historique en suivant les variations dues aux opérations d'édition, de copie, de suppression, déplacement ou autres opérations réalisées sur les fichiers ou répertoires. C'est très pratique la plupart du temps, mais il arrive que l'on souhaite appliquer les différences entre deux arborescences importées : il n'y a alors aucune relation ancestrale entre les deux arborescences et la fusion se contente de remplacer l'une par l'autre, ce qui n'est pas l'effet souhaité. L'option –ignore-ancestry ne compare plus en utilisant l'historique mais simplement en comparant les fichiers et répertoires de mêmes noms dans les arborescences :

svn merge /url1/ /url2/ /copieDeTravail/ --ignore-ancestry

En utilisant un merge sur l'url source de la copie de travail, on peut annuler les modifications ayant eu lieu entre les révisions M et N, avec M précédant N. Il suffit pour cela d'utiliser la plage de révisions inversée N:/M/ :

svn merge -r /N/:/M/ /urlSource/

Ces révisions resteront dans l'historique, mais les modifications correspondantes ne figureront plus dans le dépôt à partir du prochain commit.

Pour restaurer un fichier ou un dossier qui a été supprimé, il suffit de le copier dans le répertoire adéquat de la copie de travail en précisant la révision dans l'url :

svn cp /urlSource///fichier/@/Révision/ /répertoire//

Le commit suivant validera la restauration dans le dépôt.

Pour revenir à une ancienne version, il suffit de faire une copie de l'url de l'ancienne version vers l'url courante :

svn cp /urlSource///fichier/@/Révision/ /urlSource///fichier//

Si l'url de destination existe déjà, il faut la supprimer avant de faire la copie :

svn rm /urlSource///fichier//

La création d'une branche se fait tout simplement en créant une copie de la ligne principale du projet :

svn cp /urlDépôt//tronc /urlDépôt//branches//UneBranche/

Il suffit d'utiliser la commande checkout :

svn checkout /urlDépôt//branches//UneBranche/

On peut aussi utiliser la commande switch pour changer de branche :

svn switch /urlDépôt//branches//AutreBranche/

La fusion est souvent utilisée pour maintenir une branche à jour par rapport à la ligne principale du projet :

cd /répertoireCopieDeTravail//branches//UneBranche/
svn update
svn merge /urlDépôt//tronc

Si la branche n'est plus utile, on peut la supprimer du dépôt :

svn rm /urlDépôt//branches//UneBranche/

On peut lancer le serveur qui répond aux réquêtes svn:// avec la commande :

svnserve -d -r /racineDesDépôtsSvn/

Supposons que le dépôt source et le miroir sont sur des machines différentes. On effectue l'initialisation sur la machine qui hébergera le miroir comme suit :

svnsync init file:////miroir/ svn+ssh:///dépôt/

Le dépôt miroir doit exister et être vide.

La gestion des enregistrements sélectifs à la mode darcs record peut être activée en insérant :

[extensions]
/.../
hgext.record =

dans le fichier ~/.hgrc.

Une gestion des piles de patchs semblable à celle de quilt peut être activée en insérant :

[extensions]
/.../
hgext.mq =

dans le fichier ~/.hgrc.

Un méta-dépôt est un dépôt qui en contient plusieurs autres. Chaque sous-dépôt est placé dans un sous-répertoire appelé module. La commande submodule ajoute des modules au méta-dépôt :

git submodule add /urlModule/ /répertoireModule/

On a généralement la structure :

méta-dépôt/module-1
méta-dépôt/module-2
...

La syntaxe complète pour ssh est :

ssh:///utilisateur/@/machine//~/utilisateur///dépôt/

où dépôt est le chemin relatif par rapport au répertoire personnel de l'utilisateur.

On peut suivre l'évolution des branches distantes avec la commande :

git remote add /groupeBranches/ /source/

Si le dépôt est une copie d'un dépôt d'origine, toutes les branches de ce dépôt sont automatiquement suivies dans le groupe origin. La liste des branches distantes suivies est donnée par :

git branch -r

La commande rebase permet de déplacer le point d'attache de la branche courante sur la branche dont elle est issue. La révision destination est en argument :

git rebase /révision/

La plupart des VCS détectent automatiquement les modifications faites depuis l'enregistrement précédent et l'intégrent au commit suivant. Dans le cas de git, il faut explicitement ajouter les fichiers modifiés que l'on souhaite intégrer dans le commit par :

git add /fichiers/

Seuls ces fichiers seront intégres au commit :

git commit

Si l'on souhaite intégrer tous les fichiers modifiés sans passer par un git add, on peut faire :

git commit -a

pour prendre en compte toutes les modifications

Une fois copié, un dépôt contenant plusieurs modules se met à jour par :

git submodule init

pour initialiser la configuration, puis :

git submodule update

On peut intégrer les modifications d'autres révisions via la commande :

git cherry-pick /révision/

On peut utiliser la même disposition que dans mercurial et git, où l'historique des révisions est inclue à la racine de l'arborescence du projet :

bzr init /répertoire/

Si l'on souhaite partager un dépôt entre plusieurs branches, une disposition alternative consiste à créer un dépôt partagé dans le répertoire parent, et à créer ensuite les branches. En supposant que les répertoires existent, cela donne :

bzr init-repo /dépôt/
bzr init /dépôt///branche-1/
bzr init /dépôt///branche-2/
...

C'est la principale différence entre bazaar et les autres VCS distribués : là où mercurial utilise des variantes, des branches internes, bazaar utilise des grappes de branches partageant le même dépôt.

La copie d'une branche se fait via :

bzr branch /source/ /destination/

Lorsque la destination est le répertoire courant, on peut l'omettre :

bzr branch /source/

On peut également copier une branche en basant son historique sur la branche d'origine via l'option –stacked, ce qui permet d'économiser de l'espace disque et constitue une alternative au dépôt partagé :

bzr branch --stacked /source/ /destination/

Création :

cd ...racine
mkdir -p dépôt/branche
bzr init-repo dépôt
bzr init dépôt/branche

Importation :

cd dépôt/branche
cp -R ...projet/* .
bzr add
bzr commit

Travail :

...
bzr commit

Copie de l'autre branche :

bzr init-repo dépôt
cd dépôt
bzr branch ...racineAutreDépôt/dépôt/branche
cd branche

Fusion avec les modifications de l'autre dépôt :

bzr merge ...racineAutreDépôt/dépôt/branche
(bzr remerge --algo fichier)
(bzr resolve)
bzr commit

La création du dépôt central est analogue à celle d'un dépôt local. Vu que les copies de travail sont destinées à être distantes, on indique à bazaar via l'option –no-trees que le dépôt central ne contiendra pas de copie de travail locale :

cd ...racineCentrale
mkdir -p dépôt/branche
bzr init-repo --no-trees dépôt
bzr init dépôt/branche

Création d'une copie de travail :

cd ...racineLocale
mkdir -p dépôt
bzr init-repo dépôt
cd dépôt
bzr checkout ...racineCentrale/dépôt/branche

Importation :

cd ...racineLocale/dépôt/branche
cp -R ...projet/* .
bzr add
bzr commit

Travail :

...
bzr update
bzr commit

Travail déconnecté :

bzr unbind … bzr commit … bzr bind

Branche miroir :

cd ...racine
mkdir dépôt
bzr init-repo dépôt
cd dépôt
bzr branch ...racineSource/dépôt/branche miroir

Branche de travail :

cd ...racine/dépôt
bzr branch miroir travail

Mise à jour du miroir :

cd ...racine/dépôt/miroir
bzr pull

Mise à jour d'une branche de travail par rapport au miroir :

cd ...racine/dépôt/travail
bzr merge

Intégration des modifications d'une branche de travail :

cd ...racine/dépôt/miroir
bzr pull
bzr merge ../travail
(bzr resolve)
bzr commit
bzr push

Si le miroir est une copie de travail obtenue par un checkout au lieu d'un branch, il suffit de faire :

cd ...racine/dépôt/miroir
bzr update
bzr merge ../travail
(bzr resolve)
bzr commit