Un aperçu de la gestion de version décentralisée avec GNU Arch
Ludovic Courtès
ludovic.courtes@laas.fr

1 / 32 -- De quoi allons nous parler ?
Le sujet
  • gestion de versions (à la CVS, Subversion, etc.)
  • décentralisée (à la GNU Arch, GIT, Darcs, etc.)
Qui peut intéresser cette présentation ?
  • un utilisateur d'outils centralisés (e.g., CVS, Subversion)
  • n'importe qui ayant besoin de gestion de version, d'archivage, d'outils pour le travail en groupe, etc.
  • un geek cherchant un moyen de frimer

Introduction à la gestion de version décentralisée, motivations

2 / 32 -- Gestion de versions centralisée et décentralisée
Centralisée ?
  • un dépôt central contenant toutes les données archivées
  • impossibilité d'échanger les données entre dépôts
  • exemples : CVS, Subversion, PRCS, etc.
  • problème : utilisateurs souvent contraints de "faire sans"
Décentralisée ?
  • utilisation d'un réseau de dépôts, tous équivalents
  • approche "pair-à-pair"
  • facilité d'échange des données entre dépôts
  • s'abstrait de la frontière géographique


3 / 32 -- Premier problème : travail "hors-ligne"
Exemples
  • travailler sur un projet depuis son portable
  • sans avoir accès au réseau
Comment faire en centralisé ?
  • impossible d'accéder au dépôt (ex. : serveur CVS/Subversion)
  • donc impossible d'enregistrer des modifications
  • on se retrouve à travailler sans gestion de versions
  • ... avec les risques que ça comporte


4 / 32 -- Deuxième problème : droits d'accès au dépôt
En gestion de versions centralisée...
  • mécanismes de gestion des droits d'accès ad hoc (ex. : CVS)
  • un seul dépôt, donc point singulier de défaillance
  • souvent : limitation stricte des personnes ayant droit d'accès (ex. : projet libre)
Conséquences pratiques non désirables
  • gestion des droits d'accès spécifique, non triviale
  • utilisateur sans accès en écriture = utilisateur de seconde classe
  • on se retrouve à travailler sans gestion de versions...


5 / 32 -- Troisième problème : coopération, travail en équipe
Exemple : développement de logiciel (libre)
  • Alice veut travailler sur la fonctionnalité F0 et se moque du reste
  • Bob veut travailler sur F1 mais n'a pas accès en écriture au dépôt
Problèmes
  • Bob doit constamment mettre à jour sa copie locale (update)
  • Bob est donc perturbé par les changements relatifs à F0


6 / 32 -- Pourquoi décentraliser ? Résumé des motivations
Techniquement...
  • s'abstraire de la séparation physique entre dépôts
  • fournir une solution générale
  • faciliter la création de branches
  • faciliter l'intégration de changements faits dans d'autres branches
"Philosophiquement"...
  • faciliter la coopération sur des projets libres
  • permettre réellement un modèle de développement pair-à-pair

Introduction à GNU Arch

7 / 32 -- Remarques préliminaires
J'entends dire...
Parce que :


8 / 32 -- Historique rapide
Descendants de Arch.


9 / 32 -- Concepts de base, terminologie
archive
(= dépôt)
endroit où sont stockées les différentes versions des données
branche
identification logique d'un ensemble de travaux cohérent :
  • "la branche de Linus T."
  • "la branche 2.6 du noyau"
  • "la branche de développement de la fonctionnalité F"
révision
contenu d'une branche tel qu'admis (committed) par l'utilisateur à un moment précis.


10 / 32 -- Désignation
Attention, ne plaît pas à tout le monde ! ;-)
archive/dépôt
  • objectif : nom globalement unique sur Internet (autant que possible)
  • format (et convention) : ludo@chbouib.org--bidule-2007
branche
  • identifiant divisé en trois éléments : "catégorie", "branche" et "version"
  • format : categorie--branche--X.Y
  • exemples : linux--torvalds--2.6, linux--andrew--2.2, emacs--devel--2007
  • nom complet, globalement unique : linus@osdl.org/linux--torvalds--2.6


11 / 32 -- Désignation des révisions
Les bases
  • la première (import) : base-0
  • les suivantes : patch-1, patch-2, etc.
  • nom complet : l@c--bidule/c--b--v--patch-5
Cycle de vie d'une branche
  • possibilité de sceller une branche
Cycle de vie d'une branche.

Utilisation basique de GNU Arch

12 / 32 -- Commencer avec GNU Arch (tla)
Création d'une archive
  • protocoles possibles : système de fichiers, FTP, SFTP, HTTP
  • commande : make-archive
Accès à une archive existante
  • commande : register-archive
  • établit la correspondance entre le nom et l'URL
Création d'une branche
  • nouvelle branche : archive-setup
  • à partir d'une branche existante : tag -S


13 / 32 -- Inventaire des fichiers
CatégorieEffaçable ?Archivé ?
junk, backupouinon
preciousnonnon
sourcenonoui
unrecognized?

Classification des fichiers par nom
  • à partir de regexps
  • spécifié par branche, dans {arch}/=tagging-method


14 / 32 -- Inventaire : avantages et inconvénients
Inconvénients
  • intrusif
  • parfois redondant avec un Makefile
Intérêts
  • plus précis/complet qu'un .cvsignore
  • pratique pour l'import de nombreux fichiers
  • évite d'oublier des fichiers
  • ... ou d'en rajouter (commande lint)


15 / 32 -- Bon, et comment on "rajoute" un fichier ?
Comme souvent, il y a plusieurs façons...
Principe : chaque fichier a un identifiant
  • quand le fichier est renommé, l'identifiant ne change pas
  • permet de suivre les renommages
La méthode explicit
  • comme avec CVS, SVN, etc. : tla add fichier
La méthode tagline
  • on peut encore utiliser tla add
  • ou ajouter une ligne arch-tag dans le(s) fichier(s)


16 / 32 -- Et ensuite ?
La suite est habituelle...

Coopération avec GNU Arch

17 / 32 -- Voir ce qu'ont fait les autres


18 / 32 -- Fusion et intégration de modifications
Intégration d'un changement
  • cherry-picking : on choisit spécifiquement des modifications à "rejouer"
  • commande replay
  • toujours indépendamment de la localisation de l'autre branche
Fusion de changements
  • avec star-merge
  • applique tous les changements faits depuis la dernière fusion dans l'autre branche
  • conserve les changements locaux
  • voir les fusions : commande merges ou interface ArchWay


19 / 32 -- Bonnes pratiques pour faciliter la coopération


20 / 32 -- Intégrité et authenticité
Arch garantit l'intégrité de chaque révision
  • avec des sommes MD5/SHA1 stockées dans l'archive
Garantir l'authenticité
  • permet de certifier l'origine d'une modification
  • avec des signatures GPG
  • signature d'un changement
  • ou signature d'une révision complète


21 / 32 -- Coopération en pratique dans le libre
Par envoi de demandes de fusions
  • chacun travaille séparément
  • lorsqu'on est prêt, envoi d'une demande de fusion au mainteneur/auteur (merge request)
  • inconvénient : impossible d'envoyer les changements par courriel (le diff)
En utilisant un "gestionnaire de file de modifications" (PQM)
  • le PQM lit les courriels qui lui sont adressés
  • lorsqu'on est prêt, envoi d'une demande de fusion au PQM
  • le PQM intègre la fusion dans sa branche...
  • ... sauf si il y a conflit, échec des suites de tests, etc.

Repoussons les limites !

22 / 32 -- Création de miroirs d'archives


23 / 32 -- Mécanisme des "configurations"
Les configurations
  • exprime les dépendances (d'un logiciel) de manière précise (branche voire révision)
  • précise le répertoire où stocker chaque dépendance
Utilisation
  • projet séparé en plusieurs branches
  • sous-projets désignés par une configuration dans le projet principal
  • build-config récupère les sous-projets et les met dans les bons répertoires


24 / 32 -- Exemple de configuration

# Une configuration du noyau Linux...

# répertoire    <----->    branche à stocker
arch/i386                  l@c/linux--i386--2.6
arch/sparc                 l@c/linux--sparc--2.6
drivers                    l@c/drivers--main--2.6


25 / 32 -- Mais c'est un peu lent tout ça !
Problème de performance
  • révision obtenue par application des modifications depuis base-0
  • si en plus les révisions sont distantes...
Solution : créer un cache de révisions
  • révisions récemment utilisées disponibles instantanément
  • commandes my-library, library-config


26 / 32 -- Un cache dans l'archive
Problème : performance du premier get
  • obtention d'une branche pour la première fois
  • besoin d'appliquer beaucoup de changements, donc lent
Solution : un cache dans l'archive
  • cacherev stocke une révision complète dans l'archive
  • un get devient rapide

Critique et discussion de la concurrence

27 / 32 -- Critique de GNU Arch
Problèmes
  • performance
  • difficilement utilisable avec des très gros projets (ex. : Linux)
  • relative inefficacité du stockage
Avantages
  • fonctionnement transparent
  • format d'archive transparent, basé sur des simples fichiers
  • simple à déployer
  • puissant, robuste
  • en un mot : cool


28 / 32 -- Et la concurrence ?


29 / 32 -- Les avantages des "nouveaux"
(comparaison grossière)


30 / 32 -- Les soucis des "nouveaux"
(comparaison grossière, voire partiale...)


31 / 32 -- Conclusion


32 / 32 -- Fin !
Questions ?
http://www.gnu.org/software/gnu-arch/

https://gna.org/projects/xtla-el

http://www.nongnu.org/archway/

http://better-scm.berlios.de/



This HTML page was produced by Skribilo.
Last update: Wed Jul 04 16:02:29+0200 2007