Intégration dun gestionnaire de versions pour les documents dans le portail web de travail collaboratif

27 Chapitre 3: Intégration de système de gestion de versions dans le gestionnaire de fichiers de phpGroupWare ...29 1 Introduction...29 2 Analyse.... Figure 5: Plusieurs applications

MÉMOIRE DE FIN D'ÉTUDES

MASTER EN INFORMATIQUE

Intégration d'un gestionnaire de versions pour les documents

dans le portail 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)

Résumé

Le problème de perte de mise à jours dans l'environnement de travail collaboratif existe depuislongtemps On voudrait de pouvoir suivre ces changements pour aider les développeurs à garder lecontrôle du projet et à communiquer (même à des kilomètres de distance) tout en restant assez peuintrusif

À notre jour il y a de nombreux utiles qui nous aident à gérer des révisions par logiciel commeCVS, Subversion, Sourcesafe Ce stage vise à intégrer le gestionnaire de versions(Subversion)dans un environnement de travail collaboratif(phpGroupWare) pour remplacer WebDAV(mod_davd'Apache dans ProGet)

Dans le cadre de stage, nous avons développé un nouveau module qu'il permet de manipuler lesfichiers avec les méthodes du protocole DeltaV Ce Module est intégré dans la base de codestandard du module APIs de la nouvelle version 0.9.18 de phpGroupWare

Mots-clefs: WebDAV, DeltaV, Subversion, Filemanager, VFS

Table des matières

Remerciements 2

Résumé 3

Chapitre1: Introduction 7

1 Objectifs du stage 7

2 Contexte 7

3 Organisation du rapport 8

Chapitre 2: État de l'art 9

1 Étude de cas pour la gestion de version 9

1.1 Travail concurrent 9

1.2 Correction de bogue 9

1.3 Travail distant 10

2 CVS 10

2.1 Introduction 10

2.2 Le rôle de CVS 11

2.3 Le CVSROOT 11

2.4 Accès à une base CVS 11

2.5 Session de CVS 12

2.6 Limite de CVS 14

3 WebDAV 14

3.1 Introduction 14

3.2 Fonctionnalités 15

3.3 Méta-données 16

3.4 Gestion des accès concurrents 16

3.5 Les implémentations de serveur WebDAV 17

3.6 Limite de WebDAV 18

4 DeltaV 18

4.1 Introduction 18

4.2 Les termes dans Deltav 19

4.3 Opération de version 20

4.4 Autoversoning 21

4.5 Espace de travail (Workspace) 21

4.6 Fonctionnement de DeltaV 22

5 Étude de cas: subversion 23

5.1 Introduction 23

5.2 Avantages 24

5.3 Modèle Copier- Modifier – Fusionner 25

5.4 Subversion et Deltav 26

6 Comparaison entre Subverson et CVS 27

Chapitre 3: Intégration de système de gestion de versions dans le gestionnaire de fichiers de phpGroupWare 29

1 Introduction 29

2 Analyse 30

2.1 Subversion architecture 30

2.2 Architecture de gestionnaire de fichiers (filemanager) 31

2.3 Phpgwapi 32

3 Utiliser subversion client API 32

3.1 Construire un wrapper de libsvn_client dans PHP 33

3.2 Le cycle de vie d'une extensions 34

4 Implémenter des méthodes de protocole deltav 34

5 Implémentation 37

5.1 Introduction 37

5.2 Accès au historique 37

5.3 Comparaison la différence entre deux révision 38

Chapitre 4: Contrôle des droits d'accès 40

1 Gestion par le serveur Web apache 40

1.1 Client et serveur d’authentification Handshake 40

1.2 Méthode de Contrôle d’accès 40

1.3 Méthode de passage des certificats 41

1.4 Authentification et autorisation 41

1.5 Les phases de sécurité d’Apache 42

2 Gestion par un accès direct à subversion 43

2.1 Introduction 43

2.2 Modèle de sécurité d’Apache et Subversion 43

2.3 Autorisation 44

Conclusions 47

Bibliographie 48

Annexe A: Intégration Subverison dans Picolibre 49

Figure 5: Plusieurs applications en utilisant Delta-V 19

Figure 6: Les opérations de protocole HTTP, WebDAV et DeltaV 20

Figure 7: Représentation de l'hitorique d'un fichier foo.html dans DeltaV 23

Figure 8: Modèle copier-modifier-fusionner 26

Figure 9: Subverison Architecture 30

Figure 10: Architecture de Filemanager 32

Figure 11: Filemanager avec le wrapper de libsvn_client 33

Figure 12: Filemanager avec WebDAV/DeltaV 35

Figure 13: L'interface après avoir intégré le gestionnaire de version 38

Figure 14: Comparaison entre deux fichiers et deux répertoires 39

Figure 15: Modèle de sécurité d'Apache et Subversion 43

Figure 16: Mécanisme de NSS 50

Figure 17: Mécanisme de PAM 51

Chapitre1: Introduction

1 Objectifs du stage

L'objectif de ce stage est d'intégrer la gestion des révisions par le logiciel SubVersion dansdes 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 maximumd'utilisateurs ne souhaitant pas faire de gestion de versions, comme cela se passe dans ProGetactuellement et accessible avec un client SubVersion pour les utilisateurs désirant faire dusuivi de version, comme c'est le cas dans PicoLibre actuellement avec CVS

Le portail propose une consultation facile et rapide des informations générales sur les 115projets structurants (objectifs généraux, coordonnateurs, écoles participantes) ainsi qu'undescriptif des 5 programmes Le moteur de recherche intégré au portail permet par ailleurs unaccès direct à une information ciblée par mot clés permettant d'identifier par exemple lesprojets traitant d'une thématique particulière ou bien encore les équipes de rechercheimpliquées sur un thème

PicoLibre

Le projet PicoLibre a pour le but de développer les outils nécessaires à une plate-formecollaborative de développement de logiciel spécialement adaptée au contexte del'enseignement supérieur

Les principales caractéristiques de cette plate-forme résident dans sa simplicité (d'ó lepréfixe Pico) : simplicité d'installation et d'administration, facilité d'apprentissage etd'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 outilsmettent en musique les différents registres d’activité de la vie d’un projet - communication ausein de l’équipe, communication externe, gestion et synchronisation des développements,planification des tâches, documentation du projet, suivi de bogues, mise à disposition dessources - 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 desaccès Ainsi un projet peut être visible de tout l’Internet (accès anonyme), alors qu’un autren'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

[19]

3 Organisation du rapport

Le chapitre 2 présente les notions générales sur l'aspect de gestionnaire de version, il décritles protocoles WebDAV et DeltaV ainsi que le logiciel Subversion qui offre uneimplémentation du protocole DeltaV Dans le chapitre 3, nous abordons des possibilitésd'intégration de gestionnaire de versions dans le gestionnaire de fichiers, ainsi qu'une partie deré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ésentedes aspects de sécurité de Apache et Subversion et l'association entre les deux Le rapport setermine par des conclusions, une bibliographie et une annexe qui décrit l'intégration dusupport de subversion dans PicoLibre

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 horssite Grâce au contrôle de versions, il est possible de gérer de nombreux cas Le contrôle deversions 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 deversions et vérifient que rien ne risque de poser problème pour leurs développements de lajournée En l’occurrence, une des classes principales du système a été modifiée et lecommentaire 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 deversions qui précise ce qui a été changé Des variables d’instances ont été ajoutées, mais leursvaleurs par défaut ne semblent pas évoluer par la suite Même si ces variables peuvent poserproblème, cela ne gênera pas la journée de travail

Notre développeur ajoute une nouvelle classe et quelques tests au système Au fur et àmesure, il en informe le système de gestion des versions – les fichiers eux-mêmes ne seronttransmis que lorsqu’il les aura validés

Quelques heures plus tard, le développeur termine la première partie d’une nouvellefonctionnalité 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’équipepuissent 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 corrigerd’urgence Le développeur affecté à cette tâche extrait la version correspondante sur sondisque 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 ausystème de contrôle de versions, il pose une marque (tag) sur son code source ; il en poseraune 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 cequi 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 lacause – 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 Ilpropage ensuite la modification dans le système de contrôle de versions et pose une marquepour indiquer que le bogue a été corrigé

Il reste une question : le bogue est-il encore présent dans la version de développement ducode ? Pour le vérifier, le plus simple est de soumettre cette version au test écrit pour le codelivré 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 dedéveloppement, relancer les tests et propager la modification dans le système de contrôle deversions

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’extraireles développements en cours sur un ordinateur et de travailler Bien sûr, il faut pour cela queles propagations soient raisonnablement à jour pour éviter les conflits – et penser à propagerles 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 projetssur un serveur central appelé dépôt En utilisant les clients CVS et les outils associés, lesdéveloppeurs peuvent faire des modifications du contenu sur le serveur En fait, le dépôt CVSconserve chaque changement fait sur chaque fichier, créant ainsi un historique complet detoute l'évolution du développement du projet Les développeurs peuvent demander desversions 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 lesdéveloppeurs du projet comme répertoire central pour tous leurs travaux Les développeursapportent quotidiennement des améliorations aux sources dans le dépôt CVS Souvent, cesdéveloppeurs sont dispersés dans le monde entier ; CVS leur fournit ainsi les mécanismesné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 semarcher sur les pieds, sans perdre des données importantes ou sans être bloqués parl'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'arborescenceCVS CVSROOT est une chaîne de caractères, un peu comme une URL, qui est utilisée par lacommande CVS pour trouver le dépôt distant et qui décrit comment s'y connecter Pour rendreles 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

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, ilest 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 detravail d'un utilisateur donné doivent toujours utiliser la même méthode d'accès à la base Lechoix de la méthode d'accès s'effectue en commençant par définir la variable d'environnementCVSROOT

Figure 1: Accès à une base de CVS

2.5 Session de CVSCheckout

À l'aide d'un client CVS, chaque utilisateur souhaitant travailler sur le projet (pour modifierdes fichiers ou simplement pour voir la dernière version des fichiers dans la base) récupèreune copie de travail grâce à une opération appelée « checkout »

Figure 2: Checkout

Commit

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 peuventtravailler simultanément sur une copie du dépot et transmettre leurs modifications

Figure 3: Commit

Update

S'il arrive qu'un utilisateur tente de transmettre ses modifications alors qu'un autreutilisateur a lui-même modifié ce fichier précédemment, CVS détecte un conflit Si lesmodifications 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 peuvents'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 nesont 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érationappelée « update », afin de limiter les risques de conflits

Figure 4: Update

Release

Enfin, lorsque l'utilisateur a terminé son travail et qu'il a envoyé au serveur CVS toutes lesmodifications apportées, il peut s'il le désire vider son répertoire de travail grâce à l'opérationbaptisée « release »

CVS ne connait pas le renommage d’un fichier : si on change un fichier de nom, on perdtout l’historique de ce fichier.

Le travail sur du code tiers, ou bien les expérimentations sur le code sont pénibles car cequi 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 (commeles 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[2] est une extension du protocole HTTP/1.1[18] 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 serveursdistants Il permet de déposer, synchroniser, publier les fichiers (et dossiers) rapidement etfacilement 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 permettant d'enrichir le protocole HTTP WebDAV emploie XMLpour transmettre des données structurées dans le corps de messages au protocole HTTP, ce quilui permet de décrire des données plus complexes que celles supportées par le protocoleHTTP

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 etlister des collections, et de copier et déplacer des ressources de Web Le verrouillage desressources de Web fournit la protection contre écrasion pour tous les types de ressources deWeb (pages de HTML, images de GIF et des fichiers de source-code), et en fait, un desprincipes 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'uneproprié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 pourreprésenter des données structurées

Des applications doivent être modifiées pour interagir avec le serveur de Web qui utilise leprotocole 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 nouvellecaracté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 deWebDAV 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 serveurd'Apache, Microsoft Internet Information Server (IIS) 5, le Glyphica PortalWare, XythosStorage 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é decopier et de déplacer des pages Web et pour recevoir une liste des ressources dans unecollection 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ésdes ressources dans l'espace de nom du serveur Les opérations de l'espace de nom telles queMKCOL, MOVE, et COPY permettent à un client de créer de nouvelles collections et dedéplacer et copier des ressources La copie et le déplacement ont également des implicationssur le respect des propriétés Il semble que toutes les propriétés sur la ressource copiée oudéplacée devraient être identiques à celles de l'original

Par contre il n’existe pas réellement de gestion de versions dans WebDAV, lesmodifications 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 pasprétendre à une arborescence de développement pour visualiser l’évolution chronologique du

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 Cesinformations sur l'information (appelée les propriétés dans WebDAV, mais également connuecomme méta-données) sont particulièrement utiles dans le cas de recherche Des propriétéspeuvent être employées pour réduire le nombre de résultats non-relation d’une requête(parceque on peut chercher également sur des propriétés de ressource) Le nom d'URL permetd’ajouter des nouvelles propriétés sans devoir les enregistrer centralement Puisque tout lecontenu dans XML est codé entre le début et la fin d'une balise, des éléments additionnelspeuvent ê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ésvivantes sont contrôlées par le serveur, tandis que les propriétés mortes sont seulementstockées sur le serveur, mais sont contrôlées par le client Les propriétés sont exprimées enutilisant XML Cependant la plupart des serveurs HTTP utilisent le système de fichiers pourstocker les hiérarchies des ressources, WebDAV présente des collections commeun typespécial de ressources pour représenter et gérer les groupes de ressources Ceux sontdirectement 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 avoirfusionné d'abord les changements de l'autre auteur Pour résoudre ce problème, WebDAVutilise le verrouillage de ressource comme mécanisme de gestion d'accès concurrent Leprotocole de WebDAV ne fournit qu'un verrouillage d'écriture, mais aucun verrouillage delecture Sur le Web, par défaut une ressource est lisible, bien qu'elle puisse être protégée parcontrôle d'accès Par conséquent, le HTTP n'exige pas qu'un navigateur de Web obtienne unverrouillage afin de lire une ressource Les serveurs de Web implémente l'opération d'écriturePUT pour stocker le contenu de la ressource dans une mémoire temponl jusqu'à ce que laressource soitt transmise entièrement, puis il emploie une gestion interne d'accès concurrentpour bloquer l'accès indiqué tandis que la nouvelle valeur est rapidement mise à jour Ainsi leproblè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 estassigné à 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 desressources, telles qu'une collection et ses ressources membres Un mécanisme de découverted’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 pageWeb, il n'y a aucun concept de verrouillage de lecture Une implication de ce fait dans unenvironnement accessible en écriture de Web est que le contenu d'une ressource peut changersans avertir si un verrouillage en écriture n'est pas possédé par la ressource Le verrouillagevient souvent avec la possibilité de notification des événements de sorte qu'on puisse annonceraux 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 lescaractéristiques d'un protocole la différence principale est le type de dépôt choisit par leserveur pour stocker les propriétés et les ressources Le serveur IIS 5 de Microsoft emploie lesystème de fichiers de Windows 2000 en tant que dépôt, et fournit une intégration entre lesservices de système de fichiers et les services de WebDAV Quand un fichier est verrouillé parWebDAV, il est également verrouillé dans le système de fichiers, et par conséquent unutilisateur 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èspour déterminer si un utilisateur de WebDAV a le droit d'accès à un fichier particulier, il n'y aaucun 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 defichiers, mais exige que le serveur Apache possède tous les droits d'accès sur ces fichiers deWebDAV 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 changer la propriété des fichiers, quiimpliquerait un risque de sécurité Cela permet aussi au module mod_dav de créer des fichierspour des utilisateurs qui n'ont pas de compte local, en laissant à WebDAV la gestion desprivilèges En limitant l'accès local aux fichiers, il evite un autre problème potentiel : puisquemod_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 decontenu qui repose sur le système Versant, une base de données d'objet orienté Tous lesdocuments qui sont soumis à PortalWare sont indexés pour la recherche Le serveur destockage 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, Lesdeux 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 unefonction important: c’est la gestion de version En effet WebDAV ne nous permet pas desuivre les changements de chacun dans un l’environnement collaboratif C'est pourquoi ceprotocole doit être étendu pour gérer les versions des ressources Cette extension deWebDAV, 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[13] 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 collaborationpourront éditer le code source, les documents, les pages Web dans un projet puis enregistrersous la révision et gérer la configuration de projet Delta-v est construit sur le travail duWebDAV Le Delta-v étend le HTTP et le WebDAV avec la gestion de versions, l'isolementdes changements individuels avec les changements de collaborateurs

DeltaV utilise le modèle des ressources basées versement/emprunt pour créer les nouvellesversions d'une ressource Il présente le concept de ressource versionnée pour marquer toutesles révisions dans un historique Pour créer une ressource versionnée, un client effectue leméthode VERSION à une ressource non versionnée, ensuite le serveur remplace la ressourcenon versionnée avec la création de nouvelle ressource versionnée et crée une révision initialequi 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 à larévision par accès simplement de la ressource à travers son URL stable L'URL est appeléestable parce qu'elle ne change pas, même si la version associée à la ressource est déplacée à unendroit 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), 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 à deuxinteractions Premièrement il faut réaliser une extraction d'une copie de la ressource, on ditaussi que la ressource est importée Deuxièmement, il faut synchroniser la ressource locale etcelle du dépôt de la ressource Les contraintes de contrôle de version s'appliquent seulementpendant que la ressource est en cours de dépôt

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 lamise à 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, etcet 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, leprotocole 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 encollaboratif comme : LOCK, UNLOCK, PROPFIND, PROPATCH, COPY, MOVE,MKCOL WebDAV, DeltaV offrent 11 méthodes additionnelles qui permettent de gérer lesversions des documents

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 enusage (Working-resource) coté serveur Une ressource en usage peut être manipulée enappliquant les méthodes HTTP comme GET ou PUT pour accéder ou recouvrir la ressource enusage La méthode CHECK-IN assigne la ressource en usage à la ressource versionnée pourcréer une nouvelle révision et supprimer la ressource en usage Unn CHECKOUT annule unCHECK-OUT précédent

DeltaV présente une méthode très puissante appelée le REPORT qui fournit un mécanismeextensible 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êmeopération réalisée en utilisant DAV, nécessite un grand nombre d'échanges En effet, unPROPFIND de DAV manipule une hiérarchie des ressources dans l'espace de noms duserveur 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 etDAV :version-name de chaque version dans l’historique Pour N versions dans l’historique ondoit 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 connaissentrien sur la notion de gestion de version (c'est-à-dire qu'il ne connaissent pas les méthodesCHECK-OUT et CHECK-IN) Il est, cependant, souhaitable de fournir des mécanismes poursupporter la gestion de version pour eux Heureusement, le protocole Deltav fournit uncaractéristique de versionnement automatique (Autoversioning), qui permet à un clientWebDAV de manipuler des données sur le serveur DeltaV en laissant celui-ci réaliser unegestion automatique des versions

Il y a deux possibilité pour créer une nouvelle version de manière automatique, la premièrepossibilité c’est quand la ressource est mise à jour la seconde possibilité c’est lorsque laressource 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 LOCKquand ils veulent publier une ressource Le client prend le verrou automatiquement lorsqu'ildé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 ó une personne peut travailler en isolantces changements de ceux des autres collaborateurs qui travaillent sur le même ensemble deressources 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 sontcopiées sur le disque local du client, et tout le travail de changement a lieu sur les copieslocales (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 estbien 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 nouvellenotion, c’est la ressource en usage (Working-resource) La ressource en usage est créée sur unemprunt (CHECK-OUT), et elle correspond à un endroit sur le serveur ó 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 URLlocalement Ensuite il peut travailler sans se connecter au serveur Lorsque le client veut écrireles 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 nouvelleversion

Dans le cas d’espaces de travail, coté serveur, Il y a de nombreux d’endroit sur le serveurqui permettent d’accéder à plusieurs projets sur le serveur à travers des URLs En fait chaquecollaborateur 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 demultiple localistion physique Par contre sur le serveur, il faut implémenter des demandesadditionnelles pour isoler pour chaque collaborateur dans une partie d’espace de noms sur leserveur 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 unerequê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émaURL, cependant quand la caractéristique historique de version est supportée, chaquehistorique 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 Leserveur 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 ilajoute la propriété DAV :check-in avec la valeur de cet l’URL

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 dernierCHECK-OUT Le nom de version est stocké dans le propriété Dav :version-name de chaquerévision

5 Étude de cas: subversion

5.1 Introduction

Le projet Subversion[1] 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 leslimites 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 Laversion 1.0 est sortie au terme de 5 ans de conception et développement sponsorisé parl'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 AvantagesVersionner des fichiers, des répertoires et des métadonnées

Les répertoires, comme les fichiers, sont des objets versionnables dans Subversion Celasignifie que déplacer ou renommer un répertoire est une opération de base – les fichiers qui ysont 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 desmé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 dufichier, être fusionnées avec des révisions plus récentes, etc Les propriétés servent à gérer lamanière dont Subversion contrơle les fichiers, l’expansion des mots-clés en bref toutes ceschoses que vous préféreriez oublier La beauté de ce système est que tous les clientsSubversion peuvent y accéder – des outils tierce partie peuvent par conséquent mieuxs’intégrer à votre dépơt

Propagations atomiques et ensembles de modifications

La propagation des changements d’un utilisateur est similaire au concept de transactiondans une base de données La modification ne peut être que complètement propagée oucomplètement annulée Il est également impossible de ne voir que la moitié d’un changementlorsque quelqu’un est en train de le propager : le dépơt ne peut vous fournir que l’étatprécédant la modification ou l’état qui la suit C’est ce que l’on appelle une propagationatomique et ce qui permet de s’assurer de la cohérence de toutes les copies du dépơt Si votreconnexion réseau est coupée pendant que vous propagez une modification, celle-ci seraannulée proprement dans le dépơt

Subversion groupe vos modifications en révisions Cela fait partie intégrante du système depropagation atomique Ces révisions se voient attribuer un numéro Il est ainsi possible degrouper les modifications en unités logiques lors de leur validation, ce qui facilite leurorganisation 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 enregistrelocalement des copies originales des fichiers sur lesquels vous travaillez Ainsi, vous pouvezvoir ce que vous avez modifié sans avoir à contacter le serveur De nombreuses possibilitéssont offertes quant au type de réseau, y compris l’utilisation de SSH (Secure Shell) ou duserveur web Apache pour les dépơts disponibles publiquement

Créer des branches, marques et fusions sans cỏ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 marque, le serveur doit modifier tousles fichiers du dépơt Le modèle de base de données de Subversion rend les choses beaucoupplus rapides et simples.

Les cỏ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 deschangements qui résultent de l'opération et non de la taille du projet dans lequel leschangements 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 ilutilise 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êmefonctionner sous Windows Cela abaisse considérablement la barrière d’entrée pour les gensqui n’ont pas de serveur Unix : vous pouvez installer un serveur sur un ordinateur Windows etmigrer 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 ceschangements sur le serveur

Un exemple, ssupposant que Client1 et Client2 créent chacun un espace de travail et qu'ilsveulent modifier le fichier A Pour cela ils créent une copie de ce fichier dans l’espace detravail local et ils peuvent éditer ce fichier concurremment Client2 sauvegarde seschangements d’abord, Client1 veut sauvegarder ses changements plus tard, le serveur val'informer que ce fichier a changé depuis la dernière fois qu’il l'a copié Le serveur va luidemander de fusionner les nouveaux changements du serveur dans sa copie Si leschangements de Client1 et Client2 ne se surchargent pas entre eux, ces changements sontintégrés dans une nouvelle version locale

Dans le cas ó 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 fichierplus tard La copie de Client1 passe dans l’état de conflit Client1 doit aller voir les deuxchangements, et il choisit manuellement entre eux Dans ce cas le logiciel ne peut pas résoudre