wiki:InsiaAdminSysSvn

Version 3 (modified by Vincent Caron, 14 years ago) (diff)

--

Sommaire

Administration système - Subversion

1. Introduction

Subversion est un sytème de contrôle de version centralisé. Il a été conçu comme successeur du vénérable CVS, comme une solution plus robuste et exensible.

Un système de contrôle de version vise plusieurs objectifs:

  • permettre la collaboration entre plusieurs utilisateurs sur un projet (fichiers) commun(s)
  • permettre la maintenance smultanée de différentes versions d'un même projet
  • tracer et enregistrer l'historique de toutes les modifications effectuées
  • consulter les informations historiques, effectuer des comparaisons dans le temps

Il existe de nombreux systèmes de contrôles de version comparables, comme notamment Perforce (propriétaire).

A noter qu'il existe une famille nombreuse de système de contrôle de version dit distribuées, où il n'y a pas de distinction explicite client/server: GIT, Bazaar, Mercurial, Arch, Svk, Monotone, etc.

2. Notions fondamentales

Repository

Subversion utilisant un modèle centralisé, on peut donc désigner un serveur dont le rôle va d'être héberger un repository (dépôt). Chaque dépôt est associé avec sa méthode d'accès, ses utilisateurs, ses droits particuliers. On peut créer plusieurs dépôts distincts pour isoler des projets.

Un repository contient en particulier les données du projet et toutes ses informations historiques. Avec Subversion, la taille du repository est donc en constante augmentation. Cette augmentation est liée à la quantité de modifications apportées (et leur nature).

Serveur

Il existe plusieurs types de modèle serveur pour publier un repository. Il est en particulier en possible de s'en passer quand le client et le serveur sont sur la même machine, Subversion pouvant se contenter d'accès direct aux fichiers. Nous verrons que les autres modèles s'appellent svnserve, ssh et WebDAV.

Utilisateurs

Bien que la notion d'utilisateur soit facultative (on peut proposer une lecture/écriture pour tout le monde), elle est fondamentale pour le traçage: il est important de savoir qui a effectué quoi, même si le mécanisme d'authentification des utilisateurs n'est pas sécurisé. L'implémentation dépend du modèle serveur utilisé.

Check out, Working copy

Chaque client peut travailler sur le projet en obtenant une copie de travail grâce à une opération dite de check out. On peut donc travailler avec Subversion de manière déconnectée, la synchronisation ayant lieu qu'à des moments choisis.

Chaque client peut utiliser autant de copie de travail qu'il le souhaite, en particulier il est naturel d'en avoir une par version maintenue d'un même projet (projet-1.1, projet-1.2, etc).

Update

Un client souhaite régulièrement récupérer les dernières modifications des autres utilisateurs en mettant à jour sa copie de travail, c'est l'opération update. Celle-ci peut prendre en compte le fait que vous avez modifié des fichiers en même temps que vos collègues.

Traditionnellement, on effectue un update juste avant de commencer une séance de travail sur sa copie de travail, afin de minimaliser l'effort de synchronisation au checkin en fin de séance.

Check in, Commit

Lorsqu'on désire publier des modifications effectuées dans sa copie de travail, on effectue un checkin. Subversion est un système dit optimiste: il considère que le cas où deux personnes ont travaillé simultanément est l'exception, et ne verrouille donc aucune ressource.

Si un utilisateur a effectué des modifications en même temps que vous mais les a commitées avant vous, vous allez faire face à un conflit: il vous suffit de prendre une décision et de l'appliquer.

Subversion gère de façon intelligente les conflits: si deux personnes ont touchées à des portions différentes d'un même fichier, il peut en général résoudre le problème tout seul. Un conflit est normalement le signe d'un problème de gestion de projet et doit déclencher une résolution sur le plan organisationnel et humain !

Changeset

L'ensemble des modifications que vous publiez peut contenir différentes informations:

  • changement de contenu des fichiers
  • renommage/déplacement de fichiers, de répertoire
  • modifications d'attributs (exécution, etc)

Subversion rassemble l'ensemble de ces modifications dans une opération appelée changeset et vous garantit qu'un commit est atomique: soit l'ensemble du changeset est effectivement enregistré sur le serveur, soit il est totalement ignoré (erreur de transmission, interruption volontaire, conflit, etc).

Les changesets sont simplement numérotés à partir de 1 et leur série constitue l'historique globale du repository.

3. Utilisation pratique

Repository

Il est très simple de créer un repository, il prendra la forme d'un répertoire contenant un ensemble de fichiers variés. Il existe deux formats de repository, donc bdb qui devient obsolète (et ne fonctionne pas sur NFS). Exemple:

~/repository$ svnadmin create --fs-type fsfs projet1

Via les fichiers

On peut se passer d'un serveur spécifique et utiliser directement les fichiers, y compris via NFS pourvu que le serveur gère correctement le locking (courant avec NFSv3). Dans ce cas un client peut obtenir une copie de travail très simplement:

~/work$ svn checkout ~/repository/projet1
~/work$ cd projet1
~/work/projet1$