NGO Van Cong Responsable de stage: Christian BAC

Transcription

1 Institut de la Francophonie pour l'informatique Institut National des Télécommunications MÉMOIRE DE FIN D'ÉTUDES MASTER EN INFORMATIQUE Intégration d'un gestionnaire de versions pour les documents dans des portails Web de travail collaboratif NGO Van Cong Responsable de stage: Christian BAC Ce stage a été réalisé au sein du projet PFTCR du département Informatique de l'institut National des Télécommunications(INT) Hanoi, 6 Décembre 2006

2 Remerciements J adresse toute ma gratitude à mon responsable de stage, M. Christian BAC, pour sa disponibilité, son soutien constant et son aide précieuse durant ce stage. Je voudrais également remercier M. Olivier BERGER, M. Benoît HAMET pour leurs collaborations serrées, leurs aides tout au long de mon stage. Un grand merci à toutes les personnes du département Informatique à l'int pour leurs aides et leur gentillesse pendant mon séjour en France. Enfin, je voudrais exprimer mon entière reconnaissance envers ma famille, mes amis et les professeurs à l IFI pour leurs soutiens, leurs aides et leurs encouragements.

3 Résumé Le problème de perte de mise à jours dans l'environnement de travail collaboratif existe depuis longtemps. On voudrait pouvoir suivre ces changements pour aider les développeurs à garder le contrôle du projet et à communiquer (même à des kilomètres de distance) tout en restant assez peu intrusif. À notre jour il y a de nombreux outils qui nous aident à gérer des révisions par logiciel comme CVS, Subversion, Sourcesafe... Ce stage vise à intégrer le gestionnaire de versions(subversion) dans un envirronnement de travail collaboratif (phpgroupware) pour remplacer WebDAV (mod_dav d'apache dans ProGet). Dans le cadre de stage, nous avons développé un nouveau module qui permet de manipuler les fichiers avec les méthodes du protocole DeltaV. Ce Module est intégré dans la base de code-standard du module APIs de la nouvelle version de phpgroupware. Mots-clefs: WebDAV, DeltaV, Subversion, Filemanager, VFS.

4

5 Table des matières Chapitre1: Introduction Objectifs du stage Contexte Organisation du rapport Chapitre 2: État de l'art Étude de cas pour la gestion de version Travail concurrent Correction de bogue Travail distant CVS Introduction Le rôle de CVS Le CVSROOT Accès à une base CVS Session de CVS Limite de CVS WebDAV Introduction Fonctionnalités Méta-données Gestion des accès concurrents Les implémentations de serveur webdav Limite de webdav DeltaV Introduction Les termes dans Deltav Opération de version Autoversoning Espace de travail (Workspace) Fonctionnement de DeltaV Étude de cas: subversion Introduction Avantages Modèle Copier- Modifier Fusionner Subversion et Deltav Comparaison entre Subverson et CVS Chapitre 3: Intégration de système de gestion de versions dans le gestionnaire de fichiers de phpgroupware 27 1 Introduction Analyse Subversion architecture Architecture de gestionnaire de fichiers (filemanager) Phpgwapi Utiliser subversion client API Construire un wrapper de libsvn_client dans PHP Le cycle de vie d'une extensions Implémenter des méthodes de protocole deltav Implémentation Introduction Accès au historique Comparaison la différence entre deux révision...36

6 Chapitre 4: Contrôle des droits d'accès Gestion par le serveur Web apache Client et serveur d authentification Handshake Méthode de Contrôle d accès Méthode de passage des certificats Authentification et autorisation Les phases de sécurité d Apache Gestion par un accès direct à subversion Introduction Modèle de sécurité d Apache et Subversion Autorisation...41 Conclusions Bibliographie Annexe A: Intégration Subverison dans Picolibre

7 Table de Figure Figure 1: Accès à une base de CVS 11 Figure 2: Checkout 12 Figure 3: Commit 12 Figure 4: Update 13 Figure 5: Plusieurs applications en utilisant Delta-V 18 Figure 6: Les opérations de protocole HTTP, WebDAV et DeltaV 19 Figure 7: Représentation de l'hitorique d'un fichier foo.html dans DeltaV 21 Figure 8: Modèle copier-modifier-fusionner 24 Figure 9: Subverison Architecture 28 Figure 10: Architecture de Filemanager 30 Figure 11: Filemanger avec le wrapper de libsvn_client 31 Figure 12: Filemanger avec WebDAV/DeltaV 33 Figure 13: L'interface après avoir intégré le gestionnaire de version 36 Figure 14: Comparaison entre deux fichiers et deux répertoires 37 Figure 15: Modèle de sécurité de Apache et Subversion 41

8 Chapitre1: Introduction 1 Objectifs du stage L'objectif de ce stage est d'intégrer la gestion des révisions par le logiciel SubVersion dans des portails de travail collaboratifs appelés ProGet et PicoLibre, en replacement de CVS (Concurrent Version System) dans PicoLibre ou WebDAV (mod_dav d'apache dans ProGet). Le but est de disposer d'un même référentiel de documents partagés dans les projets qui soit à la fois accessible avec des clients DAV, de façon "transparente" pour un maximum d'utilisateurs ne souhaitant pas faire de gestion de versions, comme cela se passe dans ProGet actuellement et accessible avec un client SubVersion pour les utilisateurs désirant faire du suivi de version, comme c'est le cas dans PicoLibre actuellement avec CVS. 2 Contexte Ce stage se déroule dans le cadre d'un projet pour améliorer les plateforme ProGet et PicoLibre. ProGet Le portail ProGET présente l'ensemble des projets de recherche du GET (Groupe des Écoles des Télécomunications) répartis dans cinq programmes activités articulés autour de trois grandes thématiques - systèmes de communication, systèmes de traitement et d'élaboration de contenus, applications à la société de l'information - couvrant la totalité des activités de recherche du GET. Le portail propose une consultation facile et rapide des informations générales sur les 115 projets structurants (objectifs généraux, coordonnateurs, écoles participantes) ainsi qu'un descriptif des 5 programmes. Le moteur de recherche intégré au portail permet par ailleurs un accès direct à une information ciblée par mot clés permettant d'identifier par exemple les projets traitant d'une thématique particulière ou bien encore les équipes de recherche impliquées sur un thème. PicoLibre

9 Le projet PicoLibre a pour le but de développer les outils nécessaires à une plate-forme collaborative de développement de logiciel spécialement adaptée au contexte de l'enseignement supérieur. Les principales caractéristiques de cette plate-forme résident dans sa simplicité (d'où le préfixe Pico) : simplicité d'installation et d'administration, facilité d'apprentissage et d'utilisation par des novices. Elle permet en effet d héberger des projets en mettant à la disposition des utilisateurs un espace de travail associé à un ensemble d outils. Ces outils mettent en musique les différents registres d activité de la vie d un projet - communication au sein de l équipe, communication externe, gestion et synchronisation des développements, planification des tâches, documentation du projet, suivi de bogues, mise à disposition des sources... - et favorisent ainsi une gestion efficace, cohérente et responsable. Accessible à partir de tout navigateur WEB, la plate-forme offre une maîtrise complète de sécurisation des accès. Ainsi un projet peut être visible de tout l Internet (accès anonyme), alors qu un autre n'est accessible que par un groupe de personnes identifiées. PicoLibre est développée dans le cadre du projet PeCoRes[4]. Dans l'avenir, PicoLibre respectera le protocole d'interconnexion de plateformes de développement CoopX en cours de définition [5], et PicoLibre est un Logiciel Libre publié sous la GNU General Public License [7]. 3 Organisation du rapport Le chapitre 2 présente les notions générales sur l'aspect de gestionnaire de version, il décrit les protocoles WebDAV et DeltaV ainsi que le logiciel Subversion qui offre une implémentation du protocole DeltaV. Dans le chapitre 3, nous abordons des possibilités d'intégration de gestionnaire de versions dans le gestionnaire de fichiers, ainsi qu'une partie de réalisation qui permet de choisir entre les approches présentées. Ce chapitre 3 contient également une description des interfaces de logiciel après l'intégration. Le chapitre 4 présente des aspects de sécurité de Apache et Subversion et l'association entre les deux. Le rapprot se termine par des conclusions, une bibliographie et une annexe qui décrit l'intégration du support de subversion dans PicoLibre.

10 Chapitre 2: État de l'art 1 Étude de cas pour la gestion de version Le contrôle de versions aide les développeurs à garder le contrôle du projet. Il est possible de chercher un bogue et d appliquer un correctif à plusieurs versions de l application. Comme le système fonctionne aussi en mode déconnecté, il permet aux développeurs de travailler hors site. Grâce au contrôle de versions, il est possible de gérer de nombreux cas. Le contrôle de versions fournit maîtrise et flexibilité. 1.1 Travail concurrent Considérons les développeurs d un même projet. Avant de se mettre au travail, ils mettent à jour la copie locale du code source du projet par rapport au système central de contrôle de versions et vérifient que rien ne risque de poser problème pour leurs développements de la journée. En l occurrence, une des classes principales du système a été modifiée et le commentaire associé instille le doute dans l esprit d un des développeurs. La personne qui a fait cette modification est absente ; c est donc le système de contrôle de versions qui précise ce qui a été changé. Des variables d instances ont été ajoutées, mais leurs valeurs par défaut ne semblent pas évoluer par la suite. Même si ces variables peuvent poser problème, cela ne gênera pas la journée de travail. Notre développeur ajoute une nouvelle classe et quelques tests au

11 système. Au fur et à mesure, il en informe le système de gestion des versions les fichiers eux-mêmes ne seront transmis que lorsqu il les aura validés. Quelques heures plus tard, le développeur termine la première partie d une nouvelle fonctionnalité. Les tests ne posent pas de problème et rien n est affecté dans le reste du code ; il transfère tout au système de contrôle de versions pour que les autres membres de l équipe puissent y accéder. 1.2 Correction de bogue Un bogue est signalé dans la version du logiciel utilisée chez un client : il faut le corriger d urgence. Le développeur affecté à cette tâche extrait la version correspondante sur son disque dur et dispose maintenant de deux copies locales du code source : le tronc commun (trunk), qui suit les développements principaux, et la version livrée au client. Grâce au système de contrôle de versions, il pose une marque (tag) sur son code source ; il en posera une seconde lorsque le bogue sera corrigé. Les marques servent à identifier les points saillants du développement du code. En les nommant de manière cohérente, il est facile de suivre ce qui a été modifié. Il faut d abord isoler le problème (ce que l on fait par une série de tests) et en déterminer la cause un bogue dans un logiciel livré à un client ne devrait pas arriver, il faut éventuellement en discuter en réunion d équipe. Une fois le problème identifié, le développeur le corrige, puis il compile et teste le code. Il propage ensuite la modification dans le système de contrôle de versions et pose une marque pour indiquer que le bogue a été corrigé. Il reste une question : le bogue est-il encore présent dans la version de développement du code? Pour le vérifier, le plus simple est de soumettre cette version au test écrit pour le code livré. Fusionnez dans le tronc commun la modification propagée dans la branche de livraison. Le test échoue : le bogue est toujours présent. Il faut alors récupérer le correctif dans la version livrée et l appliquer à la version de développement, relancer les tests et propager la modification dans le système de contrôle de versions. 1.3 Travail distant Le contrôle de versions permet aussi aux développeurs de travailler depuis un site distant. Pour cela, il suffit de se connecter au dépôt par le biais d une connexion sécurisée, d extraire les développements en cours sur un ordinateur et de travailler. Bien sûr, il faut pour cela que les

12 propagations soient raisonnablement à jour pour éviter les conflits et penser à propager les modifications effectuées hors site avant de vouloir y accéder sur le dépôt central. 2 CVS 2.1 Introduction CVS est un système client/serveur qui permet aux développeurs de conserver leurs projets sur un serveur central appelé dépôt. En utilisant les clients CVS et les outils associés, les développeurs peuvent faire des modifications du contenu sur le serveur. En fait, le dépôt CVS conserve chaque changement fait sur chaque fichier, créant ainsi un historique complet de toute l'évolution du développement du projet. Les développeurs peuvent demander des versions antérieures d'un fichier particulier, regarder un historique des modifications et réaliser au besoin plusieurs autres actions utiles. 2.2 Le rôle de CVS Un nombre considérable de projets ont leur propre serveur CVS qui est utilisé par les développeurs du projet comme répertoire central pour tous leurs travaux. Les développeurs apportent quotidiennement des améliorations aux sources dans le dépôt CVS. Souvent, ces développeurs sont dispersés dans le monde entier ; CVS leur fournit ainsi les mécanismes nécessaires à l'unification de leur projet dans une structure centralisée et cohérente. CVS crée le «liant organisationnel» qui permet à ces développeurs d'améliorer leur code sans se marcher sur les pieds, sans perdre des données importantes ou sans être bloqués par l'impossiblité de mettre à jour certains fichiers critiques. 2.3 Le CVSROOT Le CVSROOT est nécessaire pour se connecter sur un dépôt CVS, vous devez, en effet, tout d'abord paramétrer un chemin appelé le CVSROOT qui décrit la racine de l'arborescence CVS. CVSROOT est une chaîne de caractères, un peu comme une URL, qui est utilisée par la commande CVS pour trouver le dépôt distant et qui décrit comment s'y connecter. Pour rendre les choses plus intéressantes, CVS supporte de nombreux formats pour CVSROOT, selon que le dépôt est local ou distant. Ces formats dépendent de la méthode utilisée pour s'y connecter.

13 2.4 Accès à une base CVS Pour pouvoir récupérer un projet, c'est-à-dire obtenir une copie de travail d'un module, il est nécessaire d'avoir accès à la base CVS. Il existe trois méthodes d'accès à une base CVS. Chaque méthode peut être utilisée simultanément avec la même base. Seules les copies de travail d'un utilisateur donné doivent toujours utiliser la même méthode d'accès à la base. Le choix de la méthode d'accès s'effectue en commençant par définir la variable d'environnement CVSROOT. Figure 1: Accès à une base de CVS

14 Checkout 2.5 Session de CVS À l'aide d'un client CVS, chaque utilisateur souhaitant travailler sur le projet (pour modifier des fichiers ou simplement pour voir la dernière version des fichiers dans la base) récupère une copie de travail grâce à une opération appelée «checkout». Commit Figure 2: Checkout Lorsque l'utilisateur a terminé de modifier les fichiers, il peut transmettre les modifications à la base. Cette opération est appelée «commit». Ainsi plusieurs développeurs peuvent travailler simultanément sur une copie du dépot et transmettre leurs modifications.

15 Figure 3: Commit Update S'il arrive qu'un utilisateur tente de transmettre ses modifications alors qu'un autre utilisateur a lui-même modifié ce fichier précédemment, CVS détecte un conflit. Si les modifications portent sur des parties différentes du fichier, le système CVS peut proposer une fusion des modifications, grâce à une opération appelée diff, sinon CVS demande à l'utilisateur de fusionner manuellement les modifications. Il est à noter que les fusions ne peuvent s'appliquer qu'aux fichiers textes. CVS peut toutefois gérer des fichiers binaires dans sa base, mais il n'a pas été prévu dans ce but. Les modifications apportées par les autres utilisateurs ne sont pas automatiquement répercutées par CVS sur la copie locale, il est donc nécessaire, avant chaque modification de fichier, de mettre à jour sa copie de travail grâce à une opération appelée «update», afin de limiter les risques de conflits Release Figure 4: Update

16 Enfin, lorsque l'utilisateur a terminé son travail et qu'il a envoyé au serveur CVS toutes les modifications apportées, il peut s'il le désire vider son répertoire de travail grâce à l'opération baptisée «release». 2.6 Limite de CVS Avec le temps, CVS n a pas évolué et ses limites semblent maintenant de moins en moins acceptables. Les commits, ou enregistrements des modifications, ne sont pas atomiques. En cas de disque plein, par exemple, on peut ne commiter qu une partie des fichiers. La raison fondamentale est que CVS gère des fichiers, pas des patches. Nous verrons que tous les outils ultérieurs considèrent que l objet élémentaire est le patch, pas le fichier. CVS ne connait pas le renommage d un fichier : si on change un fichier de nom, on perd tout l historique de ce fichier. Le travail sur du code tiers, ou bien les expérimentations sur le code sont pénibles car ce qui permet ces travaux en parallèle, les branches, sont lentes et difficiles d usage. Les répertoires ne sont pas versionnés (un répertoire est juste un container) Les méta-données ne sont pas versionnées : on ne peut pas attacher de propriétés (comme les permissions) à un fichier, par exemple. Il n y a guère de travail possible lorsqu on est déconnecté du réseau (cas d un portable). Même cvs diff demande un accès au réseau. Enfin, le code, peu clair et pas documenté, n est plus du tout maintenu. 3 WebDAV 3.1 Introduction Le protocole WebDAV est une extension du protocole HTTP/1.1 qui définit des nouvelles méthodes pour la rédaction éloignée sur le Web. Il s'agit d'un protocole normalisé d'internet, récemment adopté, permettant de simplifier la gestion de fichiers avec des serveurs distants. Il permet de déposer, synchroniser, publier les fichiers (et dossiers) rapidement et facilement. Ce protocole permet de transférer les fichiers depuis et vers le serveur Web. WebDAV ajoute les concepts de propriétés, d'opérations de l'espace de nom, de collection, et des mécanismes de verrouillage de ressource. Il définit un ensemble de nouvelles méthodes, d'en-têtes, et de codes d'état

17 permettant d'enrichir le protocole HTTP WebDAV emploie XML pour transmettre des données structurées dans le corps de messages au protocole HTTP, ce qui lui permet de décrire des données plus complexes que celles supportées par le protocole HTTP.. WebDAV est également conçu pour s'adapter aux outils existants, le rendant facile à intégrer. Les opérations de l'espace de nom de WebDAV fournissent la capacité de créer et lister des collections, et de copier et déplacer des ressources de Web. Le verrouillage des ressources de Web fournit la protection contre écrasion pour tous les types de ressources de Web (pages de HTML, images de GIF et des fichiers de source-code), et en fait, un des principes de la conception de WebDAV est de supporter tous les types de ressource Web. WebDAV fournit également la capacité de stocker et rechercher des méta-données, sous forme de paires d'attribut-valeur appelées les propriétés, liées à une ressource. Le nom d'une propriété de WebDAV est un URL, utilisé comme une propriété d'identificateur. Une valeur de propriété est décrite en XML bien formé, ce qui apporte les avantages de XML pour représenter des données structurées. Des applications doivent être modifiées pour interagir avec le serveur de Web qui utilise le protocole WebDAV, Par exemple l'internet Explorer 5 et des applications de la suite d'office 2000 ont déjà été modifiés pour intégrer le protocole WebDAV en ajoutant une nouvelle caractéristique appelée «Web Folders», ce qui permet de modifier à distance des documents de Word, d'excel, et de Powerpoint directement sur le Web. En plus, le navigateur de WebDAV fournit une interface pour naviguer le système de fichiers d'un serveur WebDAV. Il y a beaucoup de serveurs WebDAV existants, tels que le module mod_dav du serveur d'apache, Microsoft Internet Information Server (IIS) 5, le Glyphica PortalWare, Xythos Storage Server, le DataChannel RIO, le serveur d'ibm DAV4J. 3.2 Fonctionnalités Webdav autorise les changements directement sur le serveur Web, Il offre la capacité de copier et de déplacer des pages Web et pour recevoir une liste des ressources dans une collection. La possibilité de copie donne la capacité pour des changements de droit de propriété de ressource aussi bien que des modifications de ressource. Les nouvelles méthodes PROPFIND et PROPPATCH permettent à un client de récupérer et modifier des propriétés des ressources dans l'espace de nom du serveur. Les opérations de l'espace de nom telles que MKCOL, MOVE, et COPY permettent à un client de créer de nouvelles collections et de déplacer et copier des ressources. La copie et le déplacement ont également des implications sur le respect des propriétés. Il semble que toutes les

18 propriétés sur la ressource copiée ou déplacée devraient être identiques à celles de l'original. Par contre il n existe pas réellement de gestion de versions dans WebDAV, les modifications apportées par un développeur sont immédiatement intégrées et changent l état de la ressource. En conséquence, les modifications précédentes sont écrasées. On ne peut pas prétendre à une arborescence de développement pour visualiser l évolution chronologique du projet. 3.3 Méta-données Toute l'information éditée sur le Web a beaucoup d informations additionnelles associée, telle que le titre, le sujet, le créateur, l'éditeur, la longueur, et la date de création. Ces informations sur l'information (appelée les propriétés dans WebDAV, mais également connue comme méta-données) sont particulièrement utiles dans le cas de recherche. Des propriétés peuvent être employées pour réduire le nombre de (comprend pas) résultats non-relation d une requête(parce que on peut chercher également sur des propriétés de ressource).. Le nom d'url permet d ajouter des nouvelles propriétés sans devoir les enregistrer centralement. Puisque tout le contenu dans XML est codé entre le début et la fin d'une balise, des éléments additionnels peuvent être facilement ajoutés à une propriété en insérant une nouvelle balise. WebDAV distingue entre des propriétés vivantes et des propriétés mortes. Les propriétés vivantes sont contrôlées par le serveur, tandis que les propriétés mortes sont seulement stockées sur le serveur, mais sont contrôlées par le client. Les propriétés sont exprimées en utilisant XML. Cependant la plupart des serveurs HTTP utilisent le système de fichiers pour stocker les hiérarchies des ressources, WebDAV présente des collections commeun type spécial de ressources pour représenter et gérer les groupes de ressources. (???) Ceux sont directement associées aux répertoires dans un système de fichiers. 3.4 Gestion des accès concurrents Au départ, les outils de publication de Web ont rencontré «le problème de perte de mise à jour» qui se produit lorsqu'un auteur d'une page Web écrase le travail d'un autre sans avoir fusionné d'abord les changements de l'autre auteur. Pour résoudre ce problème, WebDAV utilise le verrouillage de ressource comme mécanisme de gestion d'accès concurrent. Le protocole de WebDAV ne fournit qu'un verrouillage d'écriture, mais aucun verrouillage de lecture. Sur le Web, par défaut une ressource est lisible,

19 bien qu'elle puisse être protégée par contrôle d'accès. Par conséquent, le HTTP n'exige pas qu'un navigateur de Web obtienne un verrouillage afin de lire une ressource. Les serveurs de Web implémente l'opération d'écriture PUT pour stocker le contenu de la ressource dans une mémoire temponl jusqu'à ce que la ressource soitt transmise entièrement, puis il emploie une gestion interne d'accès concurrent pour bloquer l'accès indiqué tandis que la nouvelle valeur est rapidement mise à jour. Ainsi le problème classique de lire une valeur dans un état incohérent est évité. Une autre problème, deadlock, est également évité avec des verrouillages de WebDAV. Puisqu'un verrouillage est assigné à une requête, il n'y a aucun blocage, et par conséquent aucune possibilité de deadlock. Les verrouillages peuvent être dans le cadre d'une simple ressource ou d une hiérarchie des ressources, telles qu'une collection et ses ressources membres. Un mécanisme de découverte d un verrouillage permet aux auteurs de chercher si un verrouillage existe sur une ressource. Puisque le Web est conçu de sorte qu'aucun verrouillage ne soit requis pour lire une page Web, il n'y a aucun concept de verrouillage de lecture. Une implication de ce fait dans un environnement accessible en écriture de Web est que le contenu d'une ressource peut changer sans avertir si un verrouillage en écriture n'est pas possédé par la ressource. Le verrouillage vient souvent avec la possibilité de notification des événements de sorte qu'on puisse annoncer aux collaborateurs quand un verrouillage est libéré. 3.5 Les implémentations de serveur webdav Les serveurs WebDAV peuvent utiliser différentes stratégies pour implémenter les caractéristiques d'un protocole -- la différence principale est le type de dépôt choisit par le serveur pour stocker les propriétés et les ressources. Le serveur IIS 5 de Microsoft emploie le système de fichiers de Windows 2000 en tant que dépôt, et fournit une intégration entre les services de système de fichiers et les services de WebDAV. Quand un fichier est verrouillé par WebDAV, il est également verrouillé dans le système de fichiers, et par conséquent un utilisateur local ne peut pas écrire sur un fichier verrouillé par un utilisateur à distance. IIS 5[ ] utilise également l'identité de l'utilisateur de Windows 2000 et les listes de contrôle d'accès pour déterminer si un utilisateur de WebDAV a le droit d'accès à un fichier particulier, il n'y a aucun mécanisme permettant de séparer le contrôle d'accès de la partie Web utilisé par IIS 5. En revanche, le module d'apache mod_dav utilise également un dépôt d ans le système de fichiers, mais exige que le serveur Apache possède tous les droits d'accès sur ces fichiers de WebDAV. De ce fait il empêche efficacement l'accès local aux fichiers. Ceci évite la nécessité des privilèges d super utilitateur sous UNIX pour

20 changer la propriété des fichiers, qui impliquerait un risque de sécurité. Cela permet aussi au module mod_dav de créer des fichiers pour des utilisateurs qui n'ont pas de compte local, en laissant à WebDAV la gestion des privilèges. En limitant l'accès local aux fichiers, il evite un autre problème potentiel : puisque mod_dav stocke des propriétés dans une base de données séparée, si on déplace ou supprime un fichier sans passer par le mod_dav, on risque d'obtenir des entrées de propriété dans la base de donnée pour une ressource qui n'existe plus. D'autres serveurs de WebDAV stockent leur information dans les bases de données au lieu du système de fichiers. Le serveur de Glyphica PortalWare a créé un système de gestion de contenu qui repose sur le système Versant, une base de données d'objet orienté. Tous les documents qui sont soumis à PortalWare sont indexés pour la recherche. Le serveur de stockage de Xythos utilise une base de données relationnelle pour le stockage. Le serveur de Xythos utilise le SQL standard en utilisant JDBC pour se connecter à la base de données, Les deux serveurs gagnent plusieurs avantages car le système de base de données inclut le support de transaction. 3.6 Limite de webdav Malgré que WebDAV offre des mécanismes de travaille collaboratif mais il lui manque une fonction important : c est la gestion de version. En effeti WebDAV ne nous permet pas de suivre les changements de chacun dans un l environnement collaboratif. C'est pourquoi ce protocole doit être étendu pour gérer les versions des ressources. Cette extension de WebDAV, est appelée WebDAV/DeltaV, et a été construite pour satisfaire cette demande. 4 DeltaV 4.1 Introduction Un nouveau travail qui a commencé dans l'internet Engineering Task Force (IETF) facilite le travail collaboratif à distance sur le Web. Le nouvel effort s'appelle DeltaV. Son but est de fournir la gestion de version et les possibilités de gestion de configuration pour le Web en étendant le noyau protocole du Web, HTTP. En utilisant DeltaV, les équipes de collaboration pourront éditer le code source, les documents, les pages Web dans un projet puis enregistrer sous la révision et gérer la configuration de projet. Delta-v est construit sur le travail du WebDAV. Le Delta-v étend le HTTP et le WebDAV avec la gestion de versions, l'isolement des changements individuels avec les changements de collaborateurs

21 DeltaV utilise le modèle des ressources basées versement/emprunt pour créer les nouvelles versions d'une ressource. Il présente le concept de ressource versionnée pour marquer toutes les révisions dans un historique. Pour créer une ressource versionnée, un client effectue le méthode VERSION à une ressource non versionnée, ensuite le serveur remplace la ressource non versionnée avec la création de nouvelle ressource versionnée et crée une révision initiale qui représente la ressource non versionnée. Toutes les fois qu'une nouvelle révision est créée, le serveur crée un nouveau, unique URL appelé URL stable. Un client peut accéder à la révision par accès simplement de la ressource à travers son URL stable. L'URL est appelée stable parce qu'elle ne change pas, même si la version associée à la ressource est déplacée à un endroit différent dans l'espace de nom du serveur. Le travail sur le Delta-v est continué, ainsi les détails du protocole peuvent changer pendant le processus de standardisation. Figure 5: Plusieurs applications en utilisant Delta-V 4.2 Les termes dans Deltav Le contrôle de version, dépôt des mises à jours (check-in),

22 extraction de la version courante (check-out) Le contrôle de version est un ensemble de contraintes sur la façon dont une ressource peut être mise à jour. La modification d'une ressource sous contrôle de version se fait grace à deux interactions. Premièrement il faut réaliser une extraction d'une copie de la ressource, on dit aussi que la ressource est importée. Deuxièmement, il faut synchroniser la ressource locale et celle du dépôt de la ressource. Les contraintes de contrôle de version s'appliquent seulement pendant que la ressource est en cours de dépôt. Ressource versionnable Une ressource versionnable est une ressource qui peut être mise sous contrôle de version. Ressource à version-contrôlée Quand une ressource versionnable est mise sous contrôle de version, elle devient contrôlée par celui-ci. Une telle ressource peut être CHECK-OUT afin de modifier ses propriétés ou ses contenus par des méthodes HTTP ou WebDAV. Version d'une ressource Une version de ressource est une ressource qui contient une copie d'un état particulier (propriétés ou contentes) d'une ressource à versions contrôlées. Une version est créée par la mise à jour d'une ressource dans le dépôt(check-in) qui correspond à une extraction (check-out) de ressource. Le serveur assigne un nouvel URL distinct pour chaque nouvelle version, et cet URL ne sera jamais employé pour identifier une autre ressource que cette version 4.3 Opération de version Normalement, les opérations dans le protocole HTTP sont appelées les méthodes, le protocole HTTP a définit un ensemble des méthodes (GET, HEAD, POST, OPTIONS, PUT, DELETE) et avec l apparition de WebDAV, on a ajouté des méthodes pour travailler en collaboratif comme : LOCK, UNLOCK, PROPFIND, PROPATCH, COPY, MOVE, MKCOL. WebDAV, DeltaV offrent 11 méthodes additionnelles qui permettent de gérer les versions des documents.

23 Figure 6: Les opérations de protocole HTTP, WebDAV et DeltaV L'emprunt (check-out) d'une révision avec la méthode CHECK-OUT crée une ressource en usage (Working-resource) coté serveur. Une ressource en usage peut être manipulée en appliquant les méthodes HTTP comme GET ou PUT pour accéder ou recouvrir la ressource en usage. La méthode CHECK-IN assigne la ressource en usage à la ressource versionnée pour créer une nouvelle révision et supprimer la ressource en usage. Unn CHECKOUT annule un CHECK-OUT précédent. DeltaV présente une méthode très puissante appelée le REPORT qui fournit un mécanisme extensible pour obtenir des informations sur des ressources. En particulier, cette méthode peut être employée pour rechercher les propriétés d'un ensemble de ressources. Une même opération réalisée en utilisant DAV, nécessite un grand nombre d'échanges. En effet, un PROPFIND de DAV manipule une hiérarchie des ressources dans l'espace de noms du serveur. Pour accéder à l historique d une ressource, on doit accéder au propriété Dav :version-set pour l historique de version et ensuite aux propriétés de DAV :successor et DAV :versionname de chaque version dans l historique. Pour N versions dans l historique on doit faire N+ 1 requêtes PROPFIND. La méthode REPORT facilite l accès au historique, il y a de nombreux types de REPORT que le serveur DeltaV peut générer. 4.4 Autoversoning Actuellement, il existe de nombreux de client de WebDAV et ces clients ne connaissent rien sur la notion de gestion de version (c'est-à-dire qu'il ne connaissent pas les méthodes CHECK-OUT et CHECK-IN). Il est,

24 cependant, souhaitable de fournir des mécanismes pour supporter la gestion de version pour eux. Heureusement, le protocole Deltav fournit un caractéristique de versionnement automatique (Autoversioning), qui permet à un client WebDAV de manipuler des données sur le serveur DeltaV en laissant celui-ci réaliser une gestion automatique des versions. Il y a deux possibilité pour créer une nouvelle version de manière automatique, la première possibilité c est quand la ressource est mise à jour la seconde possibilité c est lorsque la ressource est verrouillée. Dans le premier cas, on applique le modèle CHECKOUT- PUT/PROPATCH- CHECKIN et dans le deuxième cas, on utilise le modèle LOCK- CHECKOUT- CHECKIN UNLOCK. Ce modèle est bien pour les client qui utilisent LOCK quand ils veulent publier une ressource. Le client prend le verrou automatiquement lorsqu'il démarre une session et libére ce verrou en fin de session. 4.5 Espace de travail (Workspace) Un espace de travail (Workspace) est un endroit où une personne peut travailler en isolant ces changements de ceux des autres collaborateurs qui travaillent sur le même ensemble de ressources. Il y a deux grandes classes d espace de travail, de côté-client-et de côté-serveur. Dans le premier type d espace de travail,-côté client, toutes les ressources du projet sont copiées sur le disque local du client, et tout le travail de changement a lieu sur les copies locales (c'est comme dans CVS). Une fois que l édition est finie, les changements locaux sont écrits sur le serveur (utiliser PUT) et ensuite il va être versionné. L espace de travail local est bien supporté des opérations déconnectées, mais il a aussi des inconvénients, il ne permet pas à l utilisateur d accéder à l espace de travail à partir des différents localistions physiques. Puisque dans cette approche, le client maintient les états de l espace de travail de son côté le serveur connaît peu d'informations. Pour permettre cela le serveur ajoute une nouvelle notion, c est la ressource en usage (Working-resource). La ressource en usage est créée sur un emprunt (CHECK-OUT), et elle correspond à un endroit sur le serveur où le client peut écrire le contenu d une ressource empruntée quand elle est prêt à la reverser. Avec ce modèle, quand un client veut modifier un fichier, d abord il va récupérer ce fichier sur son disque local avec la commande GET de protocole HTTP et après il fait un emprunt. Cet appel crée une ressource en usage sur le serveur et retourne l'url de cette ressource au client, dans le champ «Location» de l en-tête de requête emprunt (CHECK-OUT), le client stocke cet URL localement. Ensuite il peut travailler sans se

25 connecter au serveur. Lorsque le client veut écrire les changements locaux sur le serveur, d abord il doit écrire la nouvelle valeur sur la ressource en usage et ensuite il fait un versement sur la ressource en usage pour créer une nouvelle version. Dans le cas d espaces de travail, coté serveur, Il y a de nombreux d endroit sur le serveur qui permettent d accéder à plusieurs projets sur le serveur à travers des URLs. En fait chaque collaborateur a un espace de travail personnel, mais cet espace de travail est sur le serveur. L avantage de cette implémentation c est qu on peut accéder à cet espace de travail à partir de multiple localistion physique. Par contre sur le serveur, il faut implémenter des demandes additionnelles pour isoler pour chaque collaborateur dans une partie d espace de noms sur le serveur. Pour créer un nouveau l espace de travail, on appelle la méthode MKWORKSPACE. 4.6 Fonctionnement de DeltaV Quand on veut mettre une ressource sous la gestion de versions, on peut envoyer une requête VERSION-CONTROL qui effectue trois opérations. Premièrement, elle crée un historique de versions de la ressource. Par défaut un historique de versions n est pas assigné par un URL donc il n est pas visible dans l espace de schéma URL, cependant quand la caractéristique historique de version est supportée, chaque historique de versions est associé à un URL unique sur le serveur. Deuxièmement il crée une nouvelle version en l ajoutant à l'historique de versions. Le serveur assignera un nouvel URL unique à la nouvelle ressource de version. Enfin, il convertit une ressource versonnable en une ressource sous contrôle de version. Cette ressource est identifiée par le même URL qui a identifié la ressource versionnable, et il ajoute la propriété DAV :check-in avec la valeur de cet l URL.

26 Figure 7: Représentation de l'hitorique d'un fichier foo.html dans DeltaV Sur l image ci-dessus, on peut voir que le corps de la ressource sous version-controlée est le même que celui de la version v3 plus des changements qui ont été ajoutés depuis le dernier CHECK-OUT. Le nom de version est stocké dans le propriété Dav :version-name de chaque révision. 5 Étude de cas: subversion 5.1 Introduction Le projet Subversion a été lancé par une équipe de développeurs experts de CVS. Conscients des limites de CVS, ils ont décidé de créer un système performant et moderne. Leur but n était pas de révolutionner le monde du contrôle de versions mais de corriger les limites de CVS. En général Subversion est un système de contrôle de révision, développé dans le but de remplacer CVS comme norme du contrôle de révision dans le monde du libre. La version 1.0 est sortie au terme de 5 ans de conception et développement sponsorisé par l'entreprise Collabnet, et regroupe maintenant une communauté très active. Un grand nombre de projets libres importants ont migré vers Subversion (on notera par exemple les projets KDE et Gcc, ainsi que l'apache Software Foundation). 5.2 Avantages Versionner des fichiers, des répertoires et des métadonnées

27 Les répertoires, comme les fichiers, sont des objets versionnables dans Subversion. Cela signifie que déplacer ou renommer un répertoire est une opération de base les fichiers qui y sont contenus sont déplacés automatiquement et l historique est préservé. Subversion dispose également d un mécanisme appelé «propriétés», qui associe des métadonnées aux fichiers et aux répertoires. Celles-ci sont binaires ou textuelles et sont également versionnées puisqu elles peuvent changer au fur et à mesure des modifications du fichier, être fusionnées avec des révisions plus récentes, etc. Les propriétés servent à gérer la manière dont Subversion contrôle les fichiers, l expansion des mots-clés... en bref toutes ces choses que vous préféreriez oublier. La beauté de ce système est que tous les clients Subversion peuvent y accéder des outils tierce partie peuvent par conséquent mieux s intégrer à votre dépôt. Propagations atomiques et ensembles de modifications La propagation des changements d un utilisateur est similaire au concept de transaction dans une base de données. La modification ne peut être que complètement propagée ou complètement annulée. Il est également impossible de ne voir que la moitié d un changement lorsque quelqu un est en train de le propager : le dépôt ne peut vous fournir que l état précédant la modification ou l état qui la suit. C est ce que l on appelle une propagation atomique et ce qui permet de s assurer de la cohérence de toutes les copies du dépôt. Si votre connexion réseau est coupée pendant que vous propagez une modification, celle-ci sera annulée proprement dans le dépôt. Subversion groupe vos modifications en révisions. Cela fait partie intégrante du système de propagation atomique. Ces révisions se voient attribuer un numéro. Il est ainsi possible de grouper les modifications en unités logiques lors de leur validation, ce qui facilite leur organisation et leur suivi. Fonctions réseau : copier en local, SSH, Apache... Le protocole réseau de Subversion est extrêmement efficace. De plus, cet outil enregistre localement des copies originales des fichiers sur lesquels vous travaillez. Ainsi, vous pouvez voir ce que vous avez modifié sans avoir à contacter le serveur. De nombreuses possibilités sont offertes quant au type de réseau, y compris l utilisation de SSH (Secure Shell) ou du serveur web Apache pour les dépôts disponibles publiquement. Créer des branches, marques et fusions sans coût Pour de nombreux systèmes de contrôle de versions, créer une branche est un gros travail. Sous CVS par exemple, pour créer une branche ou une

28 marque, le serveur doit modifier tous les fichiers du dépôt. Le modèle de base de données de Subversion rend les choses beaucoup plus rapides et simples. Les coûts sont proportionnels à la taille des changements et non des données En général, le temps nécessaire à une opération Subversion est proportionnel à la taille des changements qui résultent de l'opération et non de la taille du projet dans lequel les changements interviennent. C'est une des propriétés du modèle de référentiel de Subversion. Manipulation efficace des fichiers binaires Subversion est aussi efficace avec les fichiers binaires qu'avec les fichiers texte, car il utilise un algorithme différentiel pour transmettre et stocker les révisions successives. Un outil multi-plates-formes Subversion est disponible pour de nombreuses plates-formes. Le serveur peut même fonctionner sous Windows. Cela abaisse considérablement la barrière d entrée pour les gens qui n ont pas de serveur Unix : vous pouvez installer un serveur sur un ordinateur Windows et migrer sur une autre machine lorsque Subversion aura fait ses preuves 5.3 Modèle Copier- Modifier Fusionner Dans ce modèle, chaque utilisateur crée une copie de fichier sur l espace de travail local. Puis ces utilisateurs travaillent en parallèle sur leur espace local. Enfin chacun fusionne ces changements sur le serveur. Un exemple, ssupposant que Client1 et Client2 créent chacun un espace de travail. et qu'ils veulent modifier le fichier A. Pour cela ils créent une copie de ce fichier dans l espace de travail local et ils peuvent éditer ce fichier concurremment. Client2 sauvegarde ses changements d abord, Client1 veut sauvegarder ses changements plus tard, le serveur va l'informer que ce fichier a changé depuis la dernière fois qu il l'a copié. Le serveur va lui demander de fusionner les nouveaux changements du serveur dans sa copie. Si les changements de Client1 et Client2 ne se surchargent pas entre eux, ces changements sont intégrés dans une nouvelle version locale. Dans le cas où les changements de Client1 surchargent les changements de Client2, il y a un confit. Le serveur annonce à Client1 qu'il doit faire le fusion avec la version de ce fichier plus tard. La copie de Client1 passe dans l état de conflit. Client1 doit aller voir les deux changements, et il

29 choisit manuellement entre eux. Dans ce cas le logiciel ne peut pas résoudre le conflit automatiquement. Seulement le humain est capable de comprendre et de donner des choix intelligents. Une fois que Client1 a manuellement résolu le confit, il peut sauvegarder le fichier fusionné vers le serveur. Figure 8: Modèle copier-modifier-fusionner Le modèle Copier-modifier-fusionner, en pratique, fonctionne extrêmement bien. Les utilisateurs peuvent travailler en parallèle, n'attendant jamais les autres. Quand ils travaillent aux mêmes fichiers, il s'avère que la plupart de leurs changements concourants sont rares, les conflits sont peu fréquents. Et le temps pris pour résoudre des conflits est inférieur au temps perdu par un système de verrouillage 5.4 Subversion et Deltav On peut décrire différentes opérations de Subversion par DeltaV. Ceci décrit des mécanismes de base pour projeter certaines opérations. Svn checkout/list: ceci effectue un PROPFIND sur une collection pour récupérer une liste des enfants et exécute un GET sur chaque enfant. Il est recursif et se répéte dans une collection Svn commit: ceci va créer une activité avec MKACTIVITY et faire un CHECKOUT de chaque item changé et appeler ensuite un PUT de chaque nouvel item. Enfin il envoie une requête MERGE qui implique un CHECK-IN de toutes les ressources en usage.

30 Svn update/status/merge/diff 6 Comparaison entre Subverson et CVS Puisque subversion est construit pour remplacer CVS, donc il donne plusieurs caractéristiques différentes de CVS. Voici un tableau qui fait une comparaison entre CVS et SVN sur quelque aspects importants. Tags & Branches Métadonnées Type de fichier Rollback Transactio ns CVS ceux-ci sont implémentés. CVS permet de stocker seulement des fichiers. Au départ, CVS a été prévu pour le stockage de données des textes. C'est pourquoi le stockage d'autres fichiers (binaires, unicode) n'est pas trivial et exige des informations spéciales et des ajustements du côté du serveur ou du client. CVS permet de faire un retour arrière vers n'importe quel commit dans le dépôt. Dans CVS, le support des transactions par le principe «tout ou rien» est complètement absent. Par exemple, quand on enregistre plusieurs fichiers, il est possible que l'opération ne soit accomplie que pour certains de ces fichiers (dû aux conflits). SVN Les étiquettes et les branches sont réalisées par des copies et des liens sur les fichiers et les répertoires dans le dépôt. Ces copies et liens sont mémorisés sauvegarder dans l'historique des changements. SVN permet d'attacher à un fichier des attributs nommés. SVN manipule tous les types de fichier. Tous les fichiers sont considérés comme binaire. SVN ne permet pas de retour arrière vers un commit. On peut copier un bon état de dépôt à la fin du trunk pour surcharger un mauvais commit. Cependant le mauvais commit restera dans le dépôt. SVN supporte des transactions par le principe «tout ou rien».

31 Support Réseau Renomma ge CVS CVS emploie un protocole propriétaire pour son protocole de client/serveur. Ce protocole peut être canalisé au-dessus son protocole d'une connexion SSH en supportant le chiffrage. Renommage n est pas supporté et un renommage manuel peut casser l'historique en deux. SVN Le service de subversion peut employer WebDAV+DeltaV (qui est basé sur HTTP ou HTTPS) ou propriétaire qui peut passer par une connexion de SSH. Renommage est supporté

32 CVS SVN Copie Copie n'est pas supporté c'est une opération très bon marché (O (1)) elle est également utilisée pour brancher Permission de dépôt Numéro de version Version de répertoire Limité. «pré-commit hook script» peut être employé pour implémenter les systèmes de permissions. CVS gère les versions fichier par fichier. Non. L'utilisation de service basés sur WebDAV supporte la définition des permissions de HTTP pour des différents répertoires du dépôt. SVN gère les versions sur l arborescence compète. SVN garde la structure de l arborescence, il versionne non seulement les fichiers mais aussi les répertoires.

33 Chapitre 3: Intégration de système de gestion de versions dans le gestionnaire de fichiers de phpgroupware 1 Introduction Subversion emploie DeltaV pour sa communication, mais le client de Subversion est le plus souvent un client DAV, il ne connait pas l'ensemble des possibilités de DeltaV. En fait, il s'attend à quelques fonctionnalités du serveur. De plus, le serveur de subversion n'est pas,lui non plus, un serveur universel de DeltaV. Il implémente un sous-ensemble des spécifications de DeltaV. Donc un client de WebDAV ou de DeltaV peut être capable d interopérer avec lui, mais seulement si ce client opère en utilisant les fonctionnalités que le serveur implémente. De plus subversion fournit des propriétés sur des fichiers, des répertoires, et même sur le concept abstrait d'une révision. Chacune des opérations impliquant des propriétés est reportée directement aux propriétés de WebDAV, qui peuvent être manipulées par des méthodes HTTP, PROPFIND et PROPPATCH. À partir de ces idées nous pensons qu'un client WebDAV est capable de manipuler les fichiers d'un serveur DeltaV et nous pouvons également utiliser la requête PROPFIND pour récupérer la propriété «nom de version» associée avec une ressource.

34 2 Analyse 2.1 Subversion architecture Figure 9: Subverison Architecture D une côté, le dépôt de subversion tient des données versionnés et d autre côté le client de subversion gère une partie de copies des données versionnés. Entre les deux côtés il existe plusieurs méthodes pour se connecter. Pour accéder à un dépôt sur le serveur, il y a les trois méthodes d accès

35 principales suivantes : Un utilisateur local au serveur peut utiliser un client compatible subversion pour accéder directement au dépôt à travers le protocole file://urls Un utilisateur distant accéde au dépôt en utilisant svn:// ou svn+ssh://. Le processus svnserve doit être déployé sur le serveur soit comme un daemon ou soit par inetd. Enfin, on peut accéder à un dépôt en utilisant le protocole ou à travers le serveur Apache. Pour que le serveur Apache puisse fonctionner avec Subversion, on utilise un sous-module de mod_dav, c est mod_dav_svn qui permet à serveur Apache d accéder au dépôt de Subversion. Lorsque le serveur est configuré dans ce mode, si une requête demande des informations de Subversion, elle est tranférée directement au module mod_dav_svn pour traitement. Introduction 2.2 Architecture de gestionnaire de fichiers (filemanager) Le gestionnaire de fichiers de phpgroupware (filemanager) est un système qui permet de manipuler des fichiers et des répertoires de manière abstraite relativement à l'endroit où sont stockés les fichiers. Il fournit des fonctions comme : publier, télécharger, créer, éditer des fichiers et créer des répertoires. Chaque utilisateur a un répertoire «Home» et peut accéder aux répertoires partagés par des groupes d'où il est un membre. Pour travailler ensemble sur un projet les utilisateurs de phpgroupware peuvent employer un répertoire de groupe pour stocker des données partagées. Actuellement le gestionnaire de fichiers supporte trois types de stockage des données, le premier stocke des données localement sur le système de fichiers local, dans une base de données, ou sur un serveur WebDAV à distance. Si on utilise le WebDAV, on peut stocker les données en ligne ainsi plus facilement coopérer entre applications

36 Mod_dav Dans Apache Figure 10: Architecture de Filemanager Pour que le gestionnaire de fichiers puisse travailler en mode DAV on doit activer le module mod_dav sur le côté de serveur. Mod_dav implémente actuellement les Class 1 et 2 du protocole DAV, c'est-à-dire qu'il fournit toutes les fonctionnalités de DAV pour manipuler des fichiers et des répertoires et aussi ales propriétés sur ces ressources. En outre, il gère un verrouillage des ressources de sorte que les clients puissent avoir un accès

37 exclusif pour modifier des ressources. Le mod_dav a été incorporé directement dans le serveur d'apache à partir d Apache 2.0. Le serveur de DAV fonctionne au dessus du système de fichiers pour chercher et stocker les ressources et des collections de DAV (des fichiers et des répertoires). 2.3 Phpgwapi Ce paquetage fournit des bibliothèques pour développer des modules de phpgroupware, il gère la session, l utilisateur/groupe et il supporte de multiple bases de données en utilisant des méthodes de PHPLIB. Il supporte aussi l utilisation de template en utilisant le classe template de PHPLIB et l interface de système de fichiers et même une interface de i/o de réseau. Dans phpgwapi, il existe une bibliothèque qui nous aide à effectuer des méthodes de WebDAV en coordination avec le VFS (Virtual File Sytem) [ ]. 3 Utiliser subversion client API Une possibilité pour intégrer Subversion dans le gestionnaire de fichiers est l'utilisation de la bibliothèque libsvn_client de Subversion. Parmi toutes les raisons de choisir subversion, l'une des plus intéressante est que subversion a été conçu et implémenté comme une collection de bibliothèques réutilisables, écrites dans le langage C. Ceci permet à un programmes d'employer les mêmes fonctionnalités que celles des lignes de commande de client de Subversion. Quand on utilise la bibliothèque directement, d'une part on gagne en efficacité du système en évitant les démarrages de traitements pour chaque action d'autre part on gagne en exactitude. On obtient, en effet, l'accès à toute information que le client API peut nous donner, plutôt que le sousensemble limité de cette information que la ligne de commande peut nous fournir. On peut faire probablement un travail meilleur et plus complet en utilisant l'api de subversion directement. Subversion est divisé en plusieurs bibliothèques. Du point de vue du client, la bibliothèque la plus importante est libsvn_client Elle donne en particulier des fonctions pour mettre en oeuvre les diverses commandes accessibles par le client en mode la ligne de commande.

38 Figure 11: Filemanger avec le wrapper de libsvn_client 3.1 Construire un wrapper de libsvn_client dans PHP Pour construire un wrapper dans PHP il n'est pas trop difficile parce que PHP nous donne des techniques pour écrire une extension. Un ensemble des fonctions de l'espace d'utilisateur dans le langage PHP est groupé dans une extension. Maintenant il existe environ 400 extensions qui sont standardisée dans PHP. Le noyau de PHP se compose de deux morceaux séparés. Au niveau les plus bas on trouve le Zend Engine(ZE). ZE analyse un humain-lisible script et le transforme en machine-lisible jeton, et puis exécuter ces jetons dans l'espace d'un processus. ZE gère également la mémoire, la scope de variable, et dispatcher des appels de fonction. L'autre partie est le noyau de PHP qui s'occupe la communication avec la couche de SAPI (Server Application Programming Interface, également utilisé pour référencer l'environnement du serveur - Apache, à IIS etc.). 3.2 Le cycle de vie d'une extensions Quand un serveur comme Apache démarre, /usr/local/apache/bin/apachectl start, PHP commence à initialiser ses soussystèmes, à la fin de la routine de démarrage, il charge le code pour chaque extension et appelle la routine d'initialisation de chaque module. Ceci donne à chaque extension une chance d'initialiser des variables internes, d'allouer des ressources, et d'enregistrer ses fonctions avec ZE(Zend

39 Engine), ainsi si un script appelle une de ces fonctions, ZE sait quel code exécuter. Ensuite, PHP attend du serveur Web une page demandée par un client pour être traitée. Dans le cas d'apache, d'iis, ces événement se produisent lorsque des pages sont demandées par les utilisateurs à distance. Ensuite PHP commence à demander ZE(Zend Engine) d'installer un environnement pour que le script s'y exécute. Après qu'un script finit l'exécution, PHP exécute le processus de nettoyage de chaque extension. Une fois que l'exécution est accomplie, PHP attend une autre requête du serveur Web. Normalement, pour créer une nouvelle extension, on va créer trois fichiers : un fichier de source qui contient le code source de l'extension, un fichier d'en-tête contenant des références pour que le PHP puisse charger l'extension et enfin un fichier de configuration pour le processus de compilation. Il existe déjà un paquetage qui nous donne un wrapper assez complêt des fonctionnalités de libsvn_client[6]. 4 Implémenter des méthodes de protocole deltav Une autre possibilité pour intégrer le gestionnaire de version dans un gestionnaire de fichiers est d'implémenter des méthodes supportées par le gestionnaire de version dans WebDAV/DeltaV et qui manquent dans le gestionnaire de fichiers actuel.

40 Figure 12: Filemanger avec WebDAV/DeltaV

41 Pour cela, nous allons implémenter une nouvelle méthode qui supporte le gestionnaire de versions. En fait DeltaV donne une méthode très puissant appelé «REPORT», c'est un mécanisme extensible du protocole DeltaV. La valeur de REPORT peut dépendre des informations additionnelles dans le corps et l'en-tête de la requête «REPORT». Le corps de «REPORT» spécifie quel type de REPORT est exigé ainsi que les informations additionnelles qui peuvent être utilisées pour customiser le «REPORT» au dessous dans le corps de la requête nous allons spécifier le type de REPORT: «version-tree» Un exemple: REPORT /foo.html HTTP/1.1 Host: Content-Type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8"?> <D:version-tree xmlns:d="dav:"> <D:prop> <D:version-name/> <D:creator-displayname/> </D:prop> </D:version-tree> En fait la requête «REPORT:version-tree» nous permet de demander toutes les propriétés de toutes les versions dans l'historique. Normalement la réponse de cette requête au-dessus est comme suit: <?xml version="1.0" encoding="utf-8"?> <D:multistatus xmlns:d="dav:"> <D:response> <D:href> <D:propstat> <D:prop> <D:version-name>V1</D:version-name> <D:creator-displayname>Fred</D:creator-displayname> </D:prop> <D:status>HTTP/ OK</D:status> </D:propstat> </D:response> <D:response> <D:href> <D:propstat> <D:prop> <D:version-name>V2</D:version-name> <D:creator-displayname>Fred</D:creator-displayname> </D:prop> <D:status>HTTP/ OK</D:status> </D:propstat> </D:response> </D:multistatus> Dans cette réponse, elle spécifie qu'il y a trois révisions dans l'historique associé avec le fichier «foo.html», on peut retirer les informations dans chaque révision comme le nom de version avec «D:version-name» ou le

42 créateur de cette révision avec «D:creator-displayname». Mais malheureusement Subversion n'est pas une vraiment implémentation de protocole DeltaV, donc il met en oeuvre la méthode «REPORT» de façon un peu différente de la spécification de ce protocole. Actuellement le «mod_dav_svn» supporte deux type de «REPORT» c'est le «log-report» et «update-report», la forme deu corps de la méthode REPORT pour le «log-report» est comme suit : REPORT /foo.html HTTP/1.1 Host: Content-Type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8"?> <S:log-report xmlns:s="svn:" xmlns:d="dav"> <S:start-revision>398</S:start-revision> <S:end-revision>400</S:end-revision> <S:path/> <S:discover-changed-paths/> </S:log-report> Et la réponse de cette requête est aussi sous la forme d'un document XML [ ], la racine d'élément est LOG-REPORT et chaque élément commence par une balise <S:log-item> et se termine par une balise </S:log-item>. Chaque item est composé de nom de la version, date de la version et enfin le commentaire de cette version. <?xml version="1.0" encoding="utf-8"?> <S:log-report xmlns:s="svn:" xmlns:d="dav:"> <S:log-item> <D:version-name>398</D:version-name> <S:date> T15:54: Z</S:date> <D:comment>testing the commit thing yeeha </D:comment> </S:log-item> <S:log-item> <D:version-name>399</D:version-name> <S:date> T15:05: Z</S:date> <D:comment>commit</D:comment> </S:log-item> <S:log-item> <D:version-name>400</D:version-name> <S:date> T12:25: Z</S:date> <D:comment>commit</D:comment> </S:log-item> </S:log-report> 5 Implémentation 5.1 Introduction Nous avons décidé de choisir la deuxième approche pour intégrer le gestionnaire de versions dans le système de gestionnaire de fichiers parce que dans ce système il existe déjà des composants qui nous aident à manipuler un serveur DAV et de surcroît Subversion supporte

43 l'"autoversionning" caratéristique qui permet à des clients WebDAV de travailler avec un serveur DeltaV. En utilisant la deuxième approche le système intégré est plus cohérent que la première. 5.2 Accès au historique Méthode Report Pour accéder à l'historique d'une ressource nous avons implémenté la méthode REPORT du protocole DeltaV. Chaque fois que l'utilisateur veut voir l'historique d'une ressource on va envoyer une requête " REPORT " en spécifiant la plage de révisions. Le corps de la requête est similaire àc ceux que nous avons présentés ci-dessus. La réponse de la requête "REPORT" est sous forme un document XML[], donc nous avons besoin d'analyser celui-ci pour retirer les informations neccessaires. Analyseur de SAX (Simple API for XML) Puisque la sortie de REPORT est sous la forme de XML [] pour l'analyser nous avons utilisé l'analyseur SAX, En comparaison de DOM (Document Object Model) SAX a beaucoup d'avantages dans notre cas. La sortie de REPORT peut contenir des milliers de versions, dans ce cas si on utilise DOM, on peut être dans la situation d'épuisement de mémoire de l'ordinateur. En plus on a juste besoins d'analyser le résultat de REPORT une fois donc SAX est très satisfaisant dans ce cas. SAX, qui signifie "Simple API for XML", est une API d'analyse XML. Cette API est "orientée événement", ce qui la distingue de l'autre API XML implémentée par nombre d'analyseurs, le DOM (Document Object Model), basée sur la construction d une arborescence interne au document XML. SAX renvoie ainsi à l application qui manipule le document XML les «événements» (ouverture de balise, fermeture de balise, contenu textuel) qui le constituent. à l'heure actuellement SAX existe dans plusieurs langages comme java, PHP, Perl. etc SAX est événementiel, si l'on considère le flux XML entrant, il est facile de découvrir les événements : une balise ouvrante est un événement, une balise fermante un autre événement... C'est l'essentiel de cette API, une fois que l'on répond à ces deux événements, on a déjà traité un flux XML. C'est étonnamment simple, et finalement extrêmement puissant.

44 Figure 13: L'interface après avoir intégré le gestionnaire de version Sur l'image, c'est une interface du gestionnaire de fichiers après avoir intégré le gestionnaire de versions. avec le fait d'ajouter une méthode REPORT, il nous permet d'accéder à l'historique d'une ressource et après de présenter un résultat de ce type à l'utilisateur. 5.3 Comparaison la différence entre deux révision Pour comparer entre deux révisions, nous avons décidé d'utiliser le diff client de Subversion. Avec cet outil nous pouvons faire la comparaison entre les deux fichiers et même pour deux répertoires. Le résultat obtenu est analysé et affiché de façon graphique pour que l'utilisateur puisse facilement suivre les changements entre les deux révisions.

45