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

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 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)

Hanoi, 20 Décembre 2006


Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif

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 ses
professeurs à l’IFI pour leurs soutiens, leurs aides et leurs encouragements.

NGO Van Cong – Promotion 10 – IFI

2


Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif

Résumé
Le problème de perte de mise à jours dans l'environnement de travail collaboratif existe depuis
longtemps. On voudrait de 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 utiles 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 environnement 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 qu'il 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 0.9.18 de phpGroupWare.
Mots-clefs: WebDAV, DeltaV, Subversion, Filemanager, VFS.

NGO Van Cong – Promotion 10 – IFI

3


Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif

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

NGO Van Cong – Promotion 10 – IFI

4


Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif

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

NGO Van Cong – Promotion 10 – IFI

5


Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif

Table de Figure
Figure 1: Accès à une base de CVS
12
Figure 2: Checkout 12
Figure 3: Commit
13
Figure 4: Update
13
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

NGO Van Cong – Promotion 10 – IFI

6


Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif

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 plate-forme 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
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

NGO Van Cong – Promotion 10 – IFI

7


Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif

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
[19].

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 rapport se
termine par des conclusions, une bibliographie et une annexe qui décrit l'intégration du
support de subversion dans PicoLibre.

NGO Van Cong – Promotion 10 – IFI

8


Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif

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 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

NGO Van Cong – Promotion 10 – IFI

9


Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif

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 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.

NGO Van Cong – Promotion 10 – IFI

10


Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif

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.

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.

NGO Van Cong – Promotion 10 – IFI

11

Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif

Figure 1: Accès à une base de CVS

2.5 Session de CVS
Checkout
À 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 ».

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

NGO Van Cong – Promotion 10 – IFI

12


Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif

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

Figure 4: Update
Release
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 ».

NGO Van Cong – Promotion 10 – IFI

13


Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif

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[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 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 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 à

NGO Van Cong – Promotion 10 – IFI

14


Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif

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 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

NGO Van Cong – Promotion 10 – IFI

15


Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif

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 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, 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.

NGO Van Cong – Promotion 10 – IFI

16


Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif

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 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

NGO Van Cong – Promotion 10 – IFI

17


Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif

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 effet 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[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 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

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.

NGO Van Cong – Promotion 10 – IFI

18


Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif

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 à 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 (checkout) 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

NGO Van Cong – Promotion 10 – IFI

19


Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif

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.

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 :version-name 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

NGO Van Cong – Promotion 10 – IFI

20


Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif

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, 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 CHECKOUTPUT/PROPATCH- CHECKIN et dans le deuxième cas, on utilise le modèle LOCKCHECKOUT- 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

NGO Van Cong – Promotion 10 – IFI

21

Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif

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 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.

NGO Van Cong – Promotion 10 – IFI

22


Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif

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[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 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).

NGO Van Cong – Promotion 10 – IFI

23

Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif

5.2 Avantages
Versionner des fichiers, des répertoires et des métadonnées
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

NGO Van Cong – Promotion 10 – IFI

24


Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif

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 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 choisit manuellement entre eux. Dans ce cas le logiciel ne peut pas résoudre

NGO Van Cong – Promotion 10 – IFI

25