FR 2846766 A1 20040507 FR 0213647 A 20021031 DESCRIPTION DOMAINE TECHNIQUE La présente invention concerne le domaine de la gestion de configuration. La gestion de configuration est un proces5 sus industriel qui consiste à identifier des composants et, des ensembles de composants. La gestion de configuration permet notamment de travailler à plusieurs personnes sur un même ensemble de composants sans se gêner les uns les autres. ETAT DE LA TECHNIQUE Les systèmes de gestion de configuration actuels utilisent deux mécanismes d'identification. Le premier est appelé gestion de version. Il permet d'identifier des composants sources à l'aide de versions. Toute version d'un composant est construite à partir de ses parents successifs. Via cette construction, on peut 15 associer à chaque composant, un arbre de version représentant son historique. La figure 1 est un exemple d'arbre de version. Le second mécanisme permet d'identifier un produit à l'aide d'une configuration. Cette configuration est alors définie par l'ensemble des couples (composant, version) comprenant tout 20 les composants sources dont ce produit dépend. La figure 3 est un exemple représentant quatre configurations. Afin de permettre une identification individuelle de chaque composant, la gestion de version impose le processus suivant: toute modification ou série de modifications d'un com25 posant doit être explicitement encadrée par deux opérations manuelles. La première opération appelée "checkout" permet de réserver une version d'un composant et, d'en créer une copie privée. La seconde opération appelée "checkin" permet de créer une nouvelle version du composant dans le système de 30 gestion de configuration à partir de la copie privée qui a été - 2 modifiée. Ce processus s'applique sur chaque composant, pour toutes modifications et, à tous les utilisateurs du système de gestion de configuration. Il en résulte une interaction très forte sur l'environnement de travail qui est coteuse et, peut être source de rejet du processus de gestion de configuration. Le second mécanisme s'appuie sur la gestion de version et, permet d'identifier des ensembles de composants. Il autorise toutes les combinaisons de composants possibles y compris une sélection comprenant des couples (composant, version) 10 n'ayant jamais existé ensembles. La configuration composée de { ( comp, 1), ( comp2, 2)} dans la figure 3 en est un exemple. Or, seules les configurations ayant existé devraient être accessibles. Ces dernières sont représentées en pointillé dans la figure 3. Cette capacité de sélection va à l'encontre d'un principe ma15 jeur de la gestion de configuration: "on ne modifie pas le passé". Les systèmes de gestion de configuration actuels ne permettent pas d'avoir l'historique des configurations successives. L'arbre de version permet d'avoir cet historique pour un composant, mais il n'y a actuellement pas d'équivalent pour un ensemble 20 de composants. Avoir deux mécanismes d'identification distincts dans un même système de gestion de configuration est un autre inconvénient. En effet, cela nécessite d'avoir recours à des labels afin de pouvoir faire le lien entre les deux types d'identifiants 25 versions et configurations. SOMMAIRE DE L'INVENTION La présente invention concerne un procédé d'identification pour la gestion de configuration matérielle et/ou logicielle. Une configuration correspondant à une combinaison de versions 30 d'un ensemble de composants. Un composant désignant un objet matériel, un répertoire, un fichier ou un autre objet du système de fichiers. En gestion de configuration, le cycle de - 3 développement est le suivant: on part d'un état de référence identifié par une configuration (ou photo du système à un instant donné); on modifie un ensemble de composants, puis on marque l'état produit avec une nouvelle configuration et on 5 recommence... De la même manière qu'entre deux versions successives d'un composant, on peux introduire une relation entre deux configurations o l'une des deux configurations a servi de référence ou de point de départ pour construire l'autre configuration. Cette relation est l'objet central de la présente inven10 tion. Les configurations et leur relation précédente permettent de construire l'arbre de configuration qui est aussi un objet de la présente invention. La figure 2 présente un tel arbre. L'arbre de configuration est l'arbre de version de toutes les configura15 tions. Il permet d'avoir l'historique des configurations successives et donc, l'histoire des modifications à un niveau "ensemble de composants". Cet arbre de configuration apporte un modèle d'identification plus robuste à la gestion de configuration que le second mécanisme décrit précédemment. En effet, il n'autorise 20 que des combinaisons de couples (composant; version) ayant existé ensembles, c'est à dire des configurations appartenant à l'arbre de configuration. Une version d'un composant appartient au moins à la configuration dans laquelle cette version a été créée. Inverse25 ment, il n'y a au plus, qu'une seule version d'un composant dans une configuration donnée. Pour chaque composant, on peux donc introduire une association univoque entre la version d'un composant et la configuration dans laquelle la version de ce composant a été créée. Cette association, qui est aussi un ob30 jet de la présente invention, permet d'utiliser une configuration à la place d'une version pour identifier un composant individuel. On s'affranchit ainsi de la gestion de version et de son paradigme "checkout/checkin". Il reste un seul modèle d'identification pour la gestion de configuration dont le support est 35 l'arbre de configuration. Tout arbre de version d'un composant - 4 est un sous-arbre de l'arbre de configuration. Avec l'arbre de configuration, il devient inutile de stocker autant d'arbres de versions qu'il y a de composants. C'est un objet de la présente invention, que d'associer à 5 chaque configuration de l'arbre de configuration, un attribut dont la valeure est un état du cycle de vie d'une configuration. La figure 4 est un exemple de ce cycle. Un autre objet de la présente invention est de fournir un système de fichiers inclus dans un système informatique com10 prenant au moins un processeur, des moyens de mémoire et des ressources physiques et/ou logiques. Ce système de fichiers ayant la capacité d'être positionné dans différents états, correspondants à des configurations de l'arbre de configuration. C'est un objet de la présente invention que le système 15 de fichiers décrit précédemment supporte en plus des fonctions usuelles d'un système de fichiers, un automate décrivant le cycle de vie d'une configuration définie précédemment, et des fonctions permettant d'effectuer des transitions sur cet automate. C'est un objet de la présente invention que le système 20 de fichiers décrit précédemment projette sur la configuration courante, toutes modifications d'un composant décrit précédemment ou de ses métas données. Les métas données d'un composant sont désignées par l'ensemble des informations relatives à ce composant et sont stockées sur ce système de fi25 chiers. Elles comprennent notamment les dates de dernières modifications, les propriétaires ainsi que leurs autorisations d'accès sur ce composant. C'est un autre objet de la présente invention que le système de fichiers décrit précédemment, interdise les 30 précédentes modifications si la configuration courante n'est pas - 5 dans un état du cycle de vie d'une configuration autorisant ces modifications. C'est aussi un objet de la présente invention que de fournir un procédé permettant de construire le système de fichiers 5 décrit précédemment au dessus d'un autre système de fichier. L'invention sera mieux comprise à la lecture de la description qui suit, donnée à titre d'exemple, et faite en référence aux figures annexées. PR SENTATION DES FIGURES - La figure 1 représente l'arbre de version d'un composant "compl". Ce composant a quatre versions: 1, 2, 3 et 2.1. - La figure 2 représente l'arbre de configuration du système comprenant les composants "compl" et 15 "comp2" de la figure 2. - La figure 3 représente deux arbres de versions correspondant aux composants "compl" et "comp2". Les traits en pointillé désignent quatre configurations "init", " confi", "conf2" et "conf3". - La figure 4 représente le cycle de vie d'une configuration dans le MCFS sous la forme d'un automate. DESCRIPTION D'UN EXEMPLE DE R ALISATION A titre d'exemple, la présente invention peux être intégralement mise en oeuvre par le "Multiple Configuration 25 File System" (MCFS) qui a été implémenté sur un système d'exploitation de type UNIX. Le MCFS est un module qui est chargé dans le noyau du système d'exploitation. Le "Virtual File System" (VFS) est la couche du noyau qui fournit aux programmes utilisateurs l'interface d'un système de fichier. Cette - 6 couche fournit aussi une abstraction qui permet à différentes implémentations de systèmes de fichier de coexister. Le MCFS est implémenté au dessus de l'interface VFS. Il utilise donc les services d'un autre système de fichier que l'on nommera 5 SFS. Le VFS autorise le montage de différents systèmes de fichier. Ce montage permet d'attacher le MCFS à un répertoire qui devient le "point de montage". Si une commande est appliquée à un composant appartenant à ce répertoire ou un de ses sous répertoires, alors elle passe à travers le module MCFS. 10 Le MCFS joue donc le rôle de filtre entre les programmes utilisateurs et le SFS. Afin de stocker plusieurs versions d'un même composant, le MCFS utilise deux niveaux de répertoires sur le SFS ".mcfs/config/". Soit "dir/comp" le chemin d'un composant du 15 MCFS o la partie désigniée par "comp" n'est pas un répertoire et, o "dir" est composée exclusivement de répertoires. Ce composant sera stocké sous "dir/.mcfs/config/comp" dans le SES o "config" désigne soit la configuration courante si ce composant à été modifié dans la présente configuration, soit 20 la dernière configuration parente de la présente configuration dans laquelle ce composant a été modifié. Ainsi, le MCFS transforme un chemin "dir/comp" vue de l'utilisateur en chemin "dir/.mcfs/config/comp" dans le système de fichier de plus bas niveau: le SFS. Le module MCFS masque les com25 posants du SFS dont le nom commence par ".mcfs" et, le répertoire ". mcfs/" est créé avec les permissions "drwxrwxrwt" afin de pouvoir être partagé par des configurations appartenant à d'autres utilisateurs. Pour rendre accessible une version d'un composant qui n'appartient pas à la configuration courante, on 30 ajoute un suffixe précédé d'un "@" qui correspond au nom de la version, exemple: "dir/compeconfig". Ces deux niveaux de répertoires permettent de stocker toutes les versions d'un composant "comp" qui n'est pas un répertoire. Le paragraphe précédent ne traite pas du cas o "comp" 35 désigne un répertoire. Le contenu d'un répertoire est déterminé -7 par son catalogue, c'est à dire l'ensemble de ses entrées. L'ajout, la suppression ou le renommage d'un composant dans ce répertoire est une modification de ce répertoire. Le contenu de ce catalogue est susceptible d'être modifié 5 entre deux configurations. Soit "config" la configuration courante. Si un composant "comp" est ajouté au répertoire "dir", il sera stocké sous "dir/. mcfs/config/comp". Inversement si ce composant est supprimé du répertoire, sa suppression sera référencée par la création d'un fichier vide sous 10 le nom "dir/.mcfs/config/.mcfscomp". Les modifications d'un répertoire sont donc stockées au niveau d'une configuration. Le contenu d'un répertoire est défini récursivement par le contenu de ce répertoire dans sa configuration parente et, des éventuelles modifications (ajouts, suppressions et renommages). 15 Le MCFS calcule à la volée le contenu d'un répertoire à partir des répertoires creux "dir/. mcfs/ABC/" o "ABC" désigne successivement toutes les configurations ancêtres de la configurations courante. Ce système de répertoires creux permet de stocker toutes les versions d'un répertoire. Un répertoire est un objet structurel du système de fichier. Son nom est utilisé dans le chemin des composants qu'il contient. Le renommage d'un répertoire modifie donc le chemin de ces composants. Ce renommage doit être visible dans la configuration courante mais, ne doit pas interférer sur les 25 autres configurations. A cet effet, on peux distinguer deux parties dans un chemin de type SFS: "dir/.mcfs/config/comp". La première partie: "dir/.mcfs/" est structurelle. Elle peux être partagée par un ensemble de configurations et, elle indique que "comp" appartient au répertoire "dir". La seconde par30 tie: "config/comp" permet de rattacher le composant "comp" à la configuration "config". Pour un répertoire "rep" créé dans "dir" au niveau du MCFS, deux répertoires sont créés dans le SFS. Le premier a pour nom "dir/rep" et, correspond à la partie structurelle de l'arborescence. Le second a pour 35 nom "dir/. mcfs/config/rep et, permet d'indiquer au module MCFS qu'il existe un répertoire "dir/rep" dans la configuration "config". Si un répertoire "dir/old" est renommé en "dir/new", - 8 son ancien nom "dir/old" doit persister dans toutes les configurations autres que la configuration courante. Afin de procéder à ce renommage, le répertoire "dir/old" est déréferencé de la configuration courante "config" par la création d'un fichier vide 5 "dir/.mcfs/config/.mcfsold" dans le SFS. Puis, la partie structurelle du nouveau répertoire est créée avec un lien symbolique "dir/new -k dir/old" qui ne sera pas visible au niveau du MCFS. La dernière étape consiste a référencer le nouveau répertoire dans la présente configuration. Ceci est effectué par la création 10 d'un répertoire: "dir/.mcfs/config/new". Ainsi, les deux parties d'un chemin SFS permettent de renommer des répertoires qui sont des composants structurels du système de fichiers sans qu'il y ait d'incidence sur les autres configurations. Sur un système de fichiers de type UNIX, un dernier type 15 de composant nécessite une adaptation: il s'agit du lien symbolique. En effet, la destination d'un lien symbolique est écrite à l'intérieur des données de ce lien et, elle n'est pas directement filtrée par les mécanismes précédants ( contrairement au chemin de ce propre lien). Si cette destination pointe à l'intérieur d'un 20 répertoire géré par le MCFS, alors elle doit être remplacée par la destination SFS correspondante. Cette destination est écrite par l'appel système "symlink" lors de la création du lien symbolique. Comme pour tout les appels systèmes du système de fichiers, le module MCFS intercepte "symlink" et, transforme la 25 destination en chemin SFS. Inversement, l'appel système "readlink" qui permet de lire la destination d'un lien symbolique, est décodé par le module en un chemin MCFS visible des programmes utilisateurs. Le MCFS permet donc de gérer tout les types de composants d'un système de fichiers: répertoires, fi30 chiers, liens symboliques, liens durs, fichiers spéciaux, etc. Les trois paragraphes précédents et celui-ci montrent comment le module MCFS permet d'empiler un système de fichiers "multiversions" sur un système de fichiers "monoversion" en transformant à la volée, le chemin des composants. A chaque instant, un programme ne peux avoir qu'une - 9 seule configuration courante. Cette configuration est une des configurations de l'arbre de configuration. Elle permet de déterminer quelles versions de chaque composant il faut sélectionner et faire apparaître dans le MCFS pour les pro5 grammes utilisateurs. Si aucune configuration courante n'est positionnée, le MCFS fait apparaître un répertoire vide au niveau du point de montage. Le MCFS fournit une fonction "mcfssetconf' qui peux être invoquée par un programme utilisateur via l'appel système "ioctl" afin de positionner ou modi10 fier la configuration courante de l'ensemble des processus partageant le même numéro de session. Cette configuration courante est alors mémorisée par le module. Le module MCFS stocke dans le fichier ".mcfstree" situé à la racine du SFS, l'arbre de configuration du MCFS. Cette 15 arbre contient toutes les configurations. Si une configuration a servi de référence ou de point de départ pour construire une autre configuration, alors elles sont reliées par une relation "père/fils" dans l'arbre de configuration, la configuration de référence étant la configuration père. Ce fichier ". mcfstree" 20 permet aussi de stocker les états de chaque configurations. Ces états sont représentés dans la figure 4. Ils correspondent a: SESSION: La configuration est une session de travail et, peux être modifiée. - FROZEN: La configuration n'est plus modifiable et ne 25 le sera plus jamais. Elle reste cependant accessible en lecture. - SPAWNED: La configuration est utilisée comme référence. Elle possède des configurations filles. - MERGE: La configuration est en train d'être fusionnée 30 dans une autre configuration. - DEAD: La configuration ne peux plus être fusionnée ou, utilisée comme référence. - DESTROYED: La configuration est détruite du MCFS. Elle n'existe plus. Le MCFS met en oeuvre l'automate décrivant le cycle de vie d'une configuration suivant la figure 4. Dans cette fi- - 10 gure, les flèches pleines représentent des transitions qui sont associées à des fonctions: "mcfsspawn", "mcfsfroze", "mcfsdestroy", "mcfsdead", "mcfsmerge". Chacune de ces fonctions peux être invoquée par un programme utilisateur via l'appel 5 système "ioctl". Les deux flèches en pointillé "new" accompagnent "mcfsspawn". Elles indiquent qu'une nouvelle configuration est automatiquement créée dans l'état "SESSION", la configuration courante passant dans l'état "SPAWNED". L'autre flèche en pointillé "nochild" indique qu'un configura10 tion dans l'état "SPAWNED" repasse automatiquement dans l'état "FROZEN" si toutes ses configurations descendantes ont été détruites. Un composant MCFS "dir/comp" ne peux être modifié que si la configuration courante "conf' est dans l'état "SES15 SION". Si tel est le cas, alors il y a deux possibilités. La première concerne le cas o ce composant a déjà été modifié dans la présente configuration. Dans ce cas, la version du composant correspondante à la configuration courante est physiquement stockée sous le chemin SFS "dir/.mcfs/conf/comp". 20 La modification est effectuée sur l'objet pointé par ce chemin. Dans le deuxième cas, le composant n'a pas encore été modifié dans la présente configuration. La version de ce composant appartient à la dernière configuration ancêtre: "prevconf' dans laquelle ce composant a été créé ou modifié. La version de 25 ce composant est physiquement stockée sous le chemin SFS: "dir/.mcfs/prevconf/comp". Avant la modification, cette version est dupliquée dans la configuration courante, c'est à dire sous: "dir/.mcfs/conf/comp" ce qui a pour effet de créer une nouvelle version du composant et, de la rattacher à la confi30 guration courante: "conf'. Cette nouvelle version est utilisée en lieu et place de la précédente dans la configuration courante. Puis, la modification de ce composant est physiquement effectuée dans "dir/.mcfs/conf/comp" c'est à dire dans la configuration courante. Les modifications d'un composant sont donc 35 projetées dans la configuration courante et, n'affectent pas les autres configurations. Ce procédé que l'on nommera "branching on write" créé une nouvelle version d'un composant. Cette ver- - il sion est représentée par une branche sur l'arbre de configuration (figure 3). Ce procédé est utilisé sur l'ensemble des appels systèmes qui modifient le contenu d'un composant comme "write" ou, qui modifient ses métas données comme: "chown", "chmod" ou "utime". Bien que la présente invention ait été décrite avec un exemple de réalisation spécifique, cette description ne doit pas être prise dans un sens limité. D'autres mises en oeuvres ou adaptations sont possibles et, deviendront apparentes pour 10 quelqu'un ayant compris cette présente invention. Par exemple, la présente invention n'est pas limitée aux plates-formes UNIX. Elle peux aussi être mis en òuvre sur d'autres systèmes d'exploitation. De telles modifications peuvent être faites sans sortir de l'esprit ou du périmètre de la présente invention caractérisée 15 par ses revendications. APPLICATIONS INDUSTRIELLES DONT LA PR SENTE INVENTION EST SUSCEPTIBLE Avec l'arbre de configuration, cette présente invention apporte un modèle d'identification plus robuste pour la gestion 20 de configuration. De plus, la technique du "branching on write" allège la couche de communication des systèmes de gestion de configuration actuels, du paradigme "checkout/checkin". Cette présente invention rend donc le processus de gestion de configuration non intrusif et, diminue son cot. Elle est susceptible 25 d'être déployée partout o la gestion de configuration est déjà utilisée, par exemple: le développement logiciel. Cette invention a aussi le potentiel d'élargir le périmètre de la gestion de configuration. Elle peux être utilisée pour améliorer les systèmes de sauvegardes. En effet, les systèmes 30 de sauvegardes actuels effectuent des recherches exhaustives dans toute l'arborescence (contrainte spaciale) du système de fichiers, avec une périodicité déterminée (contrainte tempo- - 12 relle) qui est souvent journalière. Le système de fichiers défini par la présente invention permet de s'affranchir de ces deux contraintes. Le gel d'une configuration détermine naturellement l'instant et l'ensemble des composants à sauvegarder. Cette présente invention est aussi susceptible d'être utilisée sur tous les ordinateurs de bureau. Par exemple: une secrétaire pourra partir d'un modèle de lettre type et, y écrire directement sans recopier le fichier. La lettre d'origine reste accessible et, on sait que la nouvelle lettre en est issue. Une 10 vulgaire copie de fichier aurait perdu cet historique. Si la machine de cette même secrétaire a un bug ou un virus, elle pourra positionner le système de fichiers de la présente invention dans la configuration antérieure et repartir sans problème. Avec le procédé d'identification de la présente invention, un technicien 15 pourra déterminer l'ensemble des composants qui ont été modifiés entre les deux configurations. Ceci devrait lui faciliter la réparation. - 13 REVENDICATIONS 1. Procédé d'identification pour la gestion de configuration matérielle et/ou logicielle. Une configuration correspondant à une combinaison de versions d'un ensemble de 5 composants. Un composant désignant un objet matériel, un répertoire, un fichier ou un autre objet du système de fichiers. Ce procédé étant caractérisé par une relation entre deux configurations o l'une des deux configurations a servi de référence ou de point de départ pour construire 10 l'autre configuration. 2. Procédé d'identification selon la revendication 1 caractérisé par un arbre de configuration construit à partir des configurations et de leur relation respective. 15 3. Procédé d'identification selon l'une des revendications 1 et 2 caractérisé par une association univoque entre la version d'un composant et la configuration dans laquelle la version de ce composant a été créée. 4. Procédé d'identification selon l'une des revendications 1 à 3 caractérisé par un attribut associé à chaque configuration de l'arbre de configuration, dont la valeur est un état du cycle de vie d'une configuration. 25 5. Système de fichiers pour la mise en oeuvre du procédé d'indentification selon l'une des revendications 1 à 4. Ce système de fichiers est inclus dans un système informatique comprenant au moins un processeur, des moyens de 30 mémoire et des ressources physiques et/ou logiques. Il est caractérisé par sa capacité d'être positionné dans différents états correspondants à des configurations de l'arbre de configuration. 6. Système de fichiers selon la revendication 5 caractérisé par le support d'un automate décrivant le cycle de vie - 14 d'une configuration et fournissant des fonctions permettant d'effectuer des transitions sur cet automate. 7. Système de fichiers selon l'une des revendications 5 et 6 5 caractérisé par sa faculté de projetter sur la configuration courante, toute modification d'un composant ou de ses métas données. Les métas données d'un composant sont désignées par l'ensemble des informations relatives à ce composant et sont stockées sur ce système de fichiers. 10 8. Système de fichiers selon l'une des revendications 5 à 7 caractérisé par le fait qu'il interdit toute modification d'un composant si la configuration courante n'est pas dans un état du cycle de vie d'une configuration autorisant ces 15 modifications. 9. Système de fichiers selon l'une des revendications 5 à 8 caractérisé par une structure lui permettant de s'empiler sur un autre système de fichier en y établissant une équivalence 20 entre ses composants qui sont de nature multiversionnés et les composants monoversionnés du système de fichier sousjacent.