Comme nous l'avons déjà mentionné, chaque répertoire d'une
copie de travail Subversion contient un sous-répertoire spécial
nommé .svn qui héberge les données
administratives concernant le répertoire de la copie de travail.
Subversion utilise .svn pour gérer des
informations telles que :
à quel emplacement du dépôt les fichiers et les sous-répertoires du répertoire de la copie de travail font référence ;
quelle révision de chacun de ces fichiers et répertoires est présente dans la copie de travail ;
toute propriété définie et associée par l'utilisateur à ces fichiers et répertoires ;
une copie locale originale des fichiers de la copie de travail.
L'agencement et le contenu de la zone d'administration de la copie de travail Subversion sont considérés comme des détails de l'implémentation non-destinés à être exploités par les utilisateurs. Nous encourageons les développeurs à utiliser les API publiques ou les outils fournis avec Subversion pour accéder aux données de la copie de travail et pour les manipuler, plutôt que de lire et modifier directement ces fichiers. Les formats de fichiers employés par la bibliothèque de la copie de travail pour gérer les données administratives changent de temps en temps et l'API publique réalise un gros travail pour que l'utilisateur moyen ne s'en rende pas compte. Dans cette section, nous abordons crûment certains détails de l'implémentation pour satisfaire votre insatiable curiosité.
Le fichier entries est sûrement LE
fichier le plus important du répertoire
.svn. Il contient l'essentiel des
informations administratives concernant les éléments suivis en
versions du répertoire de la copie de travail. Ce fichier
contient l'URL du dépôt, le numéro de révision original, les
sommes de contrôle des fichiers, les horodatages des copies
originales et des propriétés, les informations d'état sur les
conflits et les actions planifiées, les dernières informations
connues sur les propagations (auteur, numéro de révision et
horodatage) et l'historique de la copie locale :
pratiquement tout ce qui intéresse un client Subversion à propos
d'un élément suivi (ou à suivre) en versions !
Les lecteurs familiers avec les répertoires administratifs
de CVS auront tout de suite reconnu que le fichier
.svn/entries a les mêmes objectifs, entre
autres choses, que l'ensemble des fichiers
CVS/Entries,
CVS/Root et
CVS/Repository combinés.
Le format du fichier .svn/entries a
changé au cours du temps. Au départ, c'était un fichier
XML ; aujourd'hui, il utilise un format personnalisé mais
toujours lisible par l'utilisateur. Le choix d'XML était
particulièrement adapté pour les premiers développeurs de
Subversion qui déboguaient fréquemment le contenu du fichier (et
le comportement associé de Subversion). Cependant, le besoin de
débogage a diminué au fur et à mesure que Subversion devenait
plus mature et le besoin de performance au profit de
l'utilisateur a alors pris le dessus. Soyez conscient que la
bibliothèque Subversion de la copie de travail met
automatiquement à niveau les copies de travail d'un format à un
autre — elle comprend les vieux formats et utilise pour
l'écriture le nouveau format — ce qui vous épargne
l'effort d'extraire une nouvelle copie de travail mais peut
aussi compliquer certaines situations : lorsque différentes
versions de Subversion essaient de partager la même copie de
travail.
Comme mentionné auparavant, le répertoire
.svn contient aussi les copies originales
(avant modification locale) des fichiers : les
« versions de base » (text-base
versions en anglais). Vous pouvez les trouver
dans le répertoire .svn/text-base. Ces
copies originales offrent tout un tas d'avantages —
identification des différences et des modifications, retour en
arrière sur les fichiers modifiés ou supprimés, tout cela sans
faire appel au réseau ; échanges plus performants avec le
serveur — mais au prix d'avoir chaque fichier stocké au
moins en double sur le disque. De nos jours, c'est pratiquement
négligeable pour la majorité des fichiers. Cependant, la
situation se détériore à mesure que vos fichiers suivis en
versions grossissent. Nous étudions dorénavant la possibilité de
rendre optionnelle la présence de ces « versions de
base ». Cependant, c'est justement quand vos fichiers
suivis en versions grossissent que l'existence des
« versions de base » devient cruciale : qui a
envie de transmettre un énorme fichier à travers le réseau juste
parce qu'il veut propager une petite modification ?
Dans le même esprit que les fichiers « versions de
base », nous avons les fichiers de propriétés qui, eux
aussi, possèdent leurs copies originales « propriétés en
version de base », situés respectivement dans
.svn/props et
.svn/prop-base. Comme les répertoires aussi
peuvent avoir des propriétés, il existe également des fichiers
.svn/dir-props et
.svn/dir-prop-base.