L'air d'un source ou source réel

Dans les chapitres précédents, nous avons vu comment trouver les fichiers par rapport à la convention de nommage :

% tla inventory --names --source
hw.c
main.c

Dans ce chapitre, il y a une nouvelle distinction : les fichiers qui ont l'air d'un source par rapport à leur nom, par rapport aux fichiers réellement sources.

Lorsque vous archivez votre projet dans l'archive, arch va stocker les fichiers qui sont réellement des sources et ignorer le reste. Nous pouvons demander quels sont les fichiers sources réels en omettant l'option --names de inventory :

% tla inventory --source
[no output]

C'est un peu plus intéressant si on inclut les propres fichiers de arch « fichiers et répertoires systèmes » dans le listing :

% tla inventory --source --all --both
{arch}
{arch}/.arch-project-tree
{arch}/=tagging-method
{arch}/hello-world
[....]

Mais ce qu'il faut noter ici c'est que hw.c et main.c ne sont pas listés. Arch pense que ce sont des sources par le nom seulement. La prochaine section indique le moyen de corriger ça, et la section d'après explique ce qui se passe réellement.

La commande add

Nous pouvons indiquer à arch que nos fichiers sont réellement des sources, et qu'ils doivent donc être archivés avec le projet, en utilisant la commande tla add :

% tla add hw.c
% tla add main.c

Et maintenant nous pouvons obtenir une meilleure réponse à :

% tla inventory --source
hw.c
main.c

Une commande complémentaire est tla delete :

% tla delete hw.c

Cela n'efface pas le fichier hw.c lui-même :

% ls
hw.c            hw.c.~1~        main.c          {arch}

mais ça l'efface de la liste officielle des sources :

% tla inventory --source
main.c

Pour la poursuite de nos exemples, nous devons remettre hw.c dans la liste :

% tla add hw.c

% tla inventory --source
hw.c
main.c

Regardons plus en profondeur ce qui se passe lorsque nous ajoutons des fichiers avec tla add.

Deux noms pour chaque fichier

Dans le monde de arch, chaque fichier source (et répertoire) de notre arborescence a deux noms : un « chemin d'accès » (file path) et un « identifiant d'inventaire » (inventory id).

Le « chemin d'accès » du fichier est le chemin relatif du fichier par rapport à la racine de l'arborescence. Il décrit où le fichier est placé dans l'arborescence.

L'« identifiant d'inventaire » du fichier est (généralement) une chaîne arbitraire unique du fichier dans l'arborescence. L'identifiant d'inventaire reste constant même si le fichier est renommé. Ainsi, alors que le chemin d'accès indique où le fichier est placé, l'identifiant d'inventaire indique quel fichier est stocké à cet endroit.

Le but de tla add est d'assigner un identifiant d'inventaire à un fichier.

Dans notre exemple, nous pouvons examiner les identifiants :

   % tla inventory --source --ids
   hw.c    x_very_long_string
   main.c  x_another_very_long_string
   ^^^^    ^^^^^^^^^^^^^^^^^^^^^^^^^^
    |                |
    |           inventory ids
file paths

Généralement, quand un fichier est déplacé, son emplacement change, mais son identifiant d'inventaire reste le même. La commande tla move nous aide pour cela. Supposons que nous fassions :

% mv hw.c hello.c

nous devrions faire ensuite :

% tla move hw.c hello.c

après quoi :

% tla inventory --source --ids
hello.c   x_very_long_string
main.c    x_another_very_long_string

Notez que hello.c a le même identifiant que celui que hw.c avait.

Nous reviendrons sur ce sujet du changement de nom plus tard, pour l'instant, revenons où nous avions démarré :

% mv hello.c hw.c
% tla move hello.c hw.c

Section rapide -- ajout de répertoires

La commande tla add peut s'appliquer aux répertoires également. Si nous avions ajouté un nouveau répertoire à l'arborescence, nous devrions l'ajouter par tla add :

% mkdir docs

% tla inventory --names --source --both
docs
hw.c
hello.c

mais

% tla inventory --source --both
hw.c
hello.c

jusqu'à

% tla add docs

et ensuite

% tla inventory --source --both
docs
hw.c
hello.c

Mais, à nouveau, pour la poursuite de notre exemple, nous n'avons pas besoin de docs. Nous pouvons faire simplement :

% rm -rf docs

Il n'est pas nécessaire d'utiliser tla delete pour un répertoire physiquement effacé.

Comment ça marche ? -- tla add

Ce que fait tla add est assez simple. Notez que quand nous avons ajouté hw.c et main.c, un nouveau répertoire a été créé :

% ls -a
.               .arch-ids       hw.c.~1~        {arch}
..              hw.c            main.c

.arch-ids est un nouveau répertoire :

% ls .arch-ids
hw.c.id         main.c.id

% cat .arch-ids/hw.c.id
very long string

Les données déterminant l'identifiant des fichiers sont stockées dans les fichiers *.id. La commande tla delete efface ces fichiers. La commande tla move les renomme.

L'identifiant d'un répertoire est stocké un peu différemment. Par exemple, quand nous avions créé le sous-répertoire docs et que l'avions ajouté avec tla add, cela a créé un fichier docs/.arch-ids/=id.

Garder les choses ordonnées et rangées

La commande :

% tla tree-lint

est utile pour garder les choses ordonnées et rangées.

tree-lint vous indiquera les identifiants pour lesquels le fichier n'existe pas. Il vous indiquera quels sont les fichiers qui passent la convention de nommage, mais pour lesquels il n'y a pas d'identifiant.

Il va également vous alerter pour les fichiers qui ne suivent pas la convention de nommage.

Identifiants d'inventaire -- Plusieurs façons de procéder

« there is more than one way to do it »

Dans ce chapitre, vous avez appris les commandes de base add, move, et delete.

Ces outils pour gérer les identifiants d'inventaire ont été choisis pour leur ressemblance, du moins superficielle, avec les commandes des systèmes tels que CVS dont de nombreux utilisateurs sont familiers.

Il y a d'autres façons de gérer les identifiants d'inventaires. Parfois les autres méthodes sont plus adaptées. Un chapitre supplémentaire devrait parler de ces techniques...

Pourquoi est-ce comme cela ? -- Le but des identifiants d'inventaire

Comme vous le verrez dans les chapitres suivants, arch est pratique pour gérer les modifications effectuées sur les arborescences et les fichiers qu'elles contiennent, et pratique pour vous indiquer l'historique des arborescences et fichiers.

Comme exemple, supposons qu'Alice et Bob soient tous les deux en train de travailler sur le projet hello-world. Dans son arborescence, Alice effectue quelques modifications sur hw.c. Dans son arborescence, Bob renomme hw.c en hello.c.

À un moment donné il est nécessaire de « synchroniser » Alice et Bob. Bob doit récupérer les modifications qu'Alice a effectuées. Alice doit récupérer le fichier renommé par Bob.

Arch fournit plusieurs mécanismes pour synchroniser -- c'est une des choses les plus importantes qu'il peut faire -- mais pratiquement toutes aboutissent au calcul et à l'application d'un changeset.

Alice peut demander à arch de créer un changeset décrivant le travail qu'elle a effectué, et ce changeset décrira les modifications qu'elle a apportées à hw.c. Bob peut créer un changeset et ce changeset décrira le renommage qu'il a effectué.

Si Alice applique le changeset de Bob à son arborescence, sa copie de hw.c devrait être renommée en hello.c. Mais un cas plus subtile est celui-ci : que ce passe-t-il si Bob applique le changeset d'Alice à son arborescence ?

Alice a modifié un fichier nommé ./hw.c, mais dans l'arborescence de Bob, cette même modification devrait être appliquée à un fichier nommé ./hello.c. Heureusement, ces deux fichiers ont le même identifiant d'inventaire :

file path               inventory id
---------               -------------

         Alice's tree:
./hw.c                  x_very_long_string
                                          \
                                           - the same long string
         Bob's tree:                      /
./hello.c               x_very_long_string

Dans le changeset d'Alice, les modifications sont décrites comme ayant été effectuées sur le fichier dont l'identifiant est x_very_long_string.

Ensuite, lorsqu'il est appliqué sur l'arborescence de Bob, arch sait qu'il faut appliquer les modifications sur le fichier ayant le même identifiant ; il sait donc que les modifications s'appliquent sur ./hello.c.

Cet exemple illustre l'utilité des identifiants d'inventaire : ils permettent à arch de décrire les modifications effectuées sur une arborescence en terme d'identité logique des fichiers plutôt que de leur emplacement physique. Il y a bien d'autres exemples plus complexes de l'utilisation des identifiants d'inventaire, mais maintenant vous avez vu le principe de base.

Pourquoi est-ce comme cela ? -- Pourquoi tla move ne déplace pas les fichiers ?

Pourquoi tla delete n'efface pas le fichier de l'arborescence ou tla move ne le renomme pas ?

Ces commandes permettent d'ajuster les identifiants dans une arborescence même si d'autres outils qui ne connaissent pas arch ont réarrangé les fichiers. Par exemple, si vous utilisez un « gestionnaire de fichiers » pour renommer vos fichiers, tla move sera toujours capable de prendre en compte les changements que le gestionnaire a effectué.

Cependant, il y a maintenant deux commandes qui modifient en même temps les identifiants et les fichiers correspondants : tla mv et tla rm. Elles fonctionnent comme leurs équivalents UNIX, avec en plus la gestion de l'identifiant.

Version du 18/09/2004 21h14 : wilk@flibuste.net--libre   docs-tla--fr--1.0     patch-102 ... base-0