Commit 2011-04-26

J'ai relancé certains tests de ma thèse et je me suis rendu compte que la version actuelle est beaucoup plus lente que la version utilisée pour écrire mon manuscrit (… et pourtant Philippe n'a pas encore commité!!).

Pour essayer de comprendre ce qui se passe et vérifier que je n'ai pas fait une erreur de manip. lors de la gestion des résultats de ma thèse, j'ai tenté de recompiler une version qui date du 22 juin 2010 (permière version CMake+icc contenant les tests de ma thèse). Évidemment ce n'est pas possible directement puisque certaines libs ont disparu entretemps (PetSc, Metis). J'ai donc modifié le source de cette version pour que ca recompile avec les nouvelles libs. Comme ce travail n'est pas négligeable, je me suis dit que ce serait bien de conserver cette “version 1232 modifiée” et qu'elle pourrait devenir une version de référence pour le futur.

J'ai donc fait une “branche SVN” à partir de cette version 1232. Pour ceux qui ne comptent jamais l'utiliser, rien ne change. Vous pouvez faire comme si je n'avais pas commité. Seul le numéro de version a augmenté légèrement (mais les sources du tronc principal que vous utilisez ne sont pas modifiées, à l'exception de comp.py - voir + bas).

Pour ceux que ça intéresse, voilà comment ça marche (j'ai relu le manuel SVN): l'idée est de créer une copie de l'état du tronc principal (trunk) du repository tel qu'il était à la version 1232 dans un autre répertoire (nommé branches/v1232). On retrouve donc, à peu de choses près, le contenu de oo_meta/trunk datant de la version 1232 dans le répertoire oo_meta/branches/v1232 de la version actuelle.

En interne, le système de copie est identique à ce qui est utilisé pour déplacer les fichiers d'un emplacement à un autre: un fichier et sa copie sont bien deux fichiers SVN différents au delà de la version où la copie a été effectuée mais ils partagent la même histoire jusqu'au moment de cette copie. heureusement, dupliquer le contenu du tronc principal dans un autre répertoire est géré de manière intelligente par SVN et seules les diffs sont stockées pour éviter de faire exploser la taille du repository.

Une fois que la copie est effectuée (ce que j'ai fait ce matin), quelqu'un qui veut travailler dans la branche n'a qu'à faire un check-out de la branche (oo_meta/branches/v1232 au lieu de oo_meta/trunk). C'est un peu comme si il travaillait dans un projet tout à fait séparé du tronc principal. Autrement dit, si il commite par la suite, le tronc principal ne sera pas modifié!

La figure ci-dessus montre un “revision graph” via Tortoise SVN. ce qui peut être déroutant pour quelqu'un qui a déjà fait des branches CVS, c'est que le numéro de version de la branche ne soit pas dérivé du numéro de la version d'origine (du genre 1232.1). En fait, c'est tout à fait cohérant avec le système de gestion SVN. Chaque numéro représente un état du repository. La version 1446 est la première version du repository qui contient la copie du tronc dans le répertoire branches. Ce n'est évidemment pas parce que le numéro de version du repository augmente que les sources du tronc sont modifiées. La situation est similaire à celle qu'on observe quand on commite des trucs dans le projet oo_nda. Cette branche est donc plutôt assimilable à un projet séparé du tronc et le lien entre le tronc et celle-ci est très faible (seule l'histoire passée des fichiers est commune).

On pourrait donc finalement se demander pourquoi faire une branche et pas bêtement créer un nouveau repository. En fait, l'intérêt de faire une branche est double: d'une part on économise de la place au sein du repository vu le stockage sous forme de diffs(je viens d'en parler) et, d'autre part, des outils existent pour patcher automatiquement le tronc principal en fonction de la branche ou l'inverse (svn merge). Il ne faut cependant pas s'attendre à des miracles et ça devient très vite très délicat. On peut également passer du tronc à la branche avec svn switch (mouais, bof…). Encore une fois, le système a des grosses limites si la branche s'éloigne trop du tronc au fil des versions.

Dans le cas de Metafor et de cette nouvelle branche v1232, le but n'est certainement pas de faire évoluer deux versions du code en parallèle et encore moins de tenter une fusion au final. On veut juste permettre à une vieille version de rester compilable sur une nouvelle machine; ceci pour mesurer des pertes de perfs par exemple ou pour detecter des bugs.

Tout ceci n'est évidemment possible que grâce à l'utilisation de CMake (c'est pour cette raison que j'ai choisi cette version 1232 et non pas une plus ancienne).

Les modifs commitées dans la branche v1232 consisteront donc principalement à des modifs de configs (fichiers .cmake) qui traduiront l'évolution des libs sur les machines. La personne qui veut recompiler cette vieille version se chargera de modifier les fichiers et de les commiter pour faire gagner du temps au prochain qui voudra recompiler.

Si cette expérience marche correctement sur le long terme, il serait aussi possible de créer des branches pour les versions “student”, “gdtech”, “techspace”, etc. Ca permettrait par exemple de corriger des petits bugs sans demander aux étudiants de migrer les cas-tests. Ca permettrait aussi de recompiler ces versions avec d'autres libs (aujourd'hui, c'est déjà possible mais celui qui s'y colle fait le travail chez lui uniquement et les modifs sont perdues dès qu'il n'en a plus besoin).

toolbox/comp.py a été modifié pour permettre le choix d'une branche lors de la compilation de Metafor. Updatez vos sources et copier ce fichiers dans votre PATH sous Linux.

— Romain BOMAN 2011/04/26 13:40