Systèmes de gestion de versions

Les systèmes de gestion de versions ont pour objectif principal de tracer les modica-tions successives apportées lors du développement d'un produit, principalement un produit logiciel. Les systèmes susamment récents permettent également d'organiser et contrôler le développement parallèle. C'est le cas notamment des systèmes libres les plus populaires, CVS [5] et SVN [65], ou du système propriétaire le plus répandu, ClearCase [1]. On peut les qualier en cela de systèmes pour l'édition collaborative. Ils fonctionnent en mode

ex-1.3. Concurrence et conscience de groupe dans les systèmes collaboratifs clusivement asynchrone en se basant sur le paradigme dit de "copier-modier-fusionner" (copy-modify-merge).

Le principe de ce mode de fonctionnement est le suivant. Un utilisateur désireux de participer à un projet de développement coopératif crée d'abord une copie des chiers à partir d'un dépôt contenant les versions stables de ces chiers. Il obtient, par cette copie, un espace de travail privé dans lequel il peut apporter librement les modications qu'il souhaite. Lorsqu'il veut rendre publiques ces modications, il doit auparavant synchroniser son espace privé avec le dépôt public qui contient éventuellement de nouvelles versions des chiers partagés produites par des utilisateurs travaillant en parallèle. Le processus de synchronisation consiste à fusionner la version courante du dépôt avec la version de l'espace privé. Une fois la fusion réalisée, la publication peut avoir lieu et conduit à la création de nouvelles versions courantes dans le dépôt public.

Dans ces systèmes, les fusions se produisent au moment où l'utilisateur réalise la syn-chronisation de son espace privé avec l'espace public. Lors de ce processus, le système indique quels chiers sont mis à jour en précisant si une fusion a été nécessaire. A l'inté-rieurs des chiers, des indications sur cette fusion ne sont disponibles que dans les cas de conits, c'est-à-dire dans les cas où l'algorithme ne parvient pas à prendre une décision seul. Dans ces cas-là, l'algorithme insère dans le texte fusionné un bloc de conit semblable à celui-ci :

<<<<<<< driver.c

exit(nerr == 0 ? SUCCESS : FAILURE); =======

exit(!!nerr); >>>>>>> 1.6

Ce bloc indique que la ligne de texte spéciée a été modiée concurremment, et que les changements se recouvrent. L'algorithme ne choisit pas entre les deux possibilités et demande à l'utilisateur de le faire. Dans tous les autres cas, c'est-à-dire dans tous les cas de fusion sans conit, aucune indication n'est fournie à l'utilisateur. En particulier, le scénario de la section 1.2 ne donnerait lieu à aucune indication de la part de l'algorithme, les changements concurrents se produisant sur deux lignes distinctes et donc ne conduisant pas à un conit.

Dans ces systèmes, et en particulier dans CVS [5], il est interdit de publier des -chiers contenant des blocs de conits : les utilisateurs doivent impérativement résoudre ces conits avant de créer de nouvelles versions dans le dépôt public. Il est clair que cet impératif rend l'approche inappropriée dans le cas de la réalisation d'un Wiki P2P. En

eet, nous avons expliqué plus haut la nécessité d'avoir une fusion déterministe qui ne doit donc pas faire appel à l'utilisateur. De plus, une telle approche conduirait les serveurs à attendre l'intervention d'un utilisateur avant de continuer à intégrer des modications. Diérents serveurs pourraient ainsi être bloqués sur diérents conits avec le risque de conduire le système à un blocage généralisé.

Des eorts ont été réalisés pour améliorer la conscience de la concurrence dans ces systèmes de gestion de version. C'est notamment le cas de deux approches assez voisines, les State Treemap [44] et le système Palantír [62]. Ces deux systèmes ont pour principe de permettre à l'utilisateur de visualiser l'état des chiers de son espace privé vis-à-vis de l'es-pace public (localement modié, nouvelle version, modication concurrente en cours. . . ) et d'y ajouter une mesure de l'écart entre la version locale et la version publique. Cette mesure indique la "sévérité" de la concurrence, et permet à l'utilisateur d'anticiper des dicultés de fusion. Dans les deux cas, la granularité reste le chier : aucune information n'est fournie par le système sur les parties d'un même document modiées en concurrence. Ces dernières années, des systèmes de gestion de versions distribuées sont apparus. Ils permettent la collaboration asynchrone sans serveur central gérant une copie de référence. Dans ce sens, ils sont assez proches d'un wiki P2P. La diérence réside dans le fait que dans un tel système, il n'y a pas réellement d'espace public visible par tous les utilisateurs. Le système est organisé en un réseau d'espaces de travail, chacun était géré par un utilisateur. Chaque espace contient l'ensemble des versions des documents appartenant à cet espace. Les modications introduites par un utilisateur dans son espace privé sont publiées vers un ou plusieurs autres espaces privés. Les utilisateurs responsables de ces espaces peuvent alors décider de les intégrer. Les synchronisations entre espaces privés sont donc là aussi à l'initiative et sous le contrôle des utilisateurs. Les fusions se produisent lors de ces synchronisations, dans les espaces privés. Les notications de changements concurrents sont limitées à l'insertion de blocs de conits dans les chiers fusionnés contenant des modications concurrentes non résolues. Par contre, dans certains de ces systèmes de gestion de versions distribuées, et notamment dans GIT [22], il est possible de publier des chiers contenant des blocs de conits. Le système fait l'hypothèse que l'utilisateurs intégrant une version contenant des blocs de conits se chargera de résoudre ces conits. Cette hypothèse n'est pas valide dans un wiki P2P, où la publication se fait dans un espace public où toutes les modications sont intégrées. Il pourrait alors arriver qu'un bloc de conit créé par un serveur pour représenter une fusion d'opérations concurrentes soit lui-même créé de façon concurrente à d'autres modications. Cette situation conduirait à la création d'un nouveau bloc de conit sur chaque serveur de manière concurrente. Les blocs de conits risquent alors de croître sans n, entraînant le système dans une boucle