SVNBOOK Chap8 Inside the Working Copy Administration Area

De Framalang Wiki.

Cette page fait partie du projet Version control with subversion.

Pseudo Code Rôle Statut
hotshot92 Traduction Fait
SVF Relecture Fait
Validation

Source : http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.developer.insidewc


Inside the Working Copy Administration Area

Inside the Working Copy Administration Area
Au cœur de la zone d'administration de la copie locale

As we mentioned earlier, each directory of a Subversion working copy contains a special subdirectory called .svn that houses administrative data about that working copy directory. Subversion uses the information in .svn to keep track of things such as:

  • Which repository location(s) are represented by the files and subdirectories in the working copy directory
  • What revision of each of those files and directories is currently present in the working copy
  • Any user-defined properties that might be attached to those files and directories
  • Pristine (unedited) copies of the working copy files

The Subversion working copy administration area's layout and contents are considered implementation details not really intended for human consumption. Developers are encouraged to use Subversion's public APIs, or the tools that Subversion provides, to access and manipulate the working copy data, instead of directly reading or modifying those files. The file formats employed by the working copy library for its administrative data do change from time to time—a fact that the public APIs do a great job of hiding from the average user. In this section, we expose some of these implementation details sheerly to appease your overwhelming curiosity.

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 font référence les fichiers et les sous-répertoires dans le répertoire de la copie de travail ;
  • 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 des humains. 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é.

The Entries File

The Entries File
Le fichier «entries»

Perhaps the single most important file in the .svn directory is the entries file. It contains the bulk of the administrative information about the versioned items in a working copy directory. This one file tracks the repository URLs, pristine revision, file checksums, pristine text and property timestamps, scheduling and conflict state information, last-known commit information (author, revision, timestamp), local copy history—practically everything that a Subversion client is interested in knowing about a versioned (or to-be-versioned) resource!

Folks familiar with CVS's administrative directories will have recognized at this point that Subversion's .svn/entries file serves the purposes of, among other things, CVS's CVS/Entries, CVS/Root, and CVS/Repository files combined.

The format of the .svn/entries file has changed over time. Originally an XML file, it now uses a custom—though still human-readable—file format. While XML was a great choice for early developers of Subversion who were frequently debugging the file's contents (and Subversion's behavior in light of them), the need for easy developer debugging has diminished as Subversion has matured and has been replaced by the user's need for snappier performance. Be aware that Subversion's working copy library automatically upgrades working copies from one format to another—it reads the old formats and writes the new—which saves you the hassle of checking out a new working copy, but can also complicate situations where different versions of Subversion might be trying to use the same working copy.

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 version 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), l'historique de la copie locale — pratiquement tout ce qui intéresse un client Subversion à propos d'un élément suivi (ou à suivre) en version !

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

Pristine Copies and Property Files

Pristine Copies and Property Files
Copies originales et propriétés des fichiers

As mentioned before, the .svn directory also holds the pristine “text-base” versions of files. You can find those in .svn/text-base. The benefits of these pristine copies are multiple—network-free checks for local modifications and difference reporting, network-free reversion of modified or missing files, more efficient transmission of changes to the server—but they come at the cost of having each versioned file stored at least twice on disk. These days, this seems to be a negligible penalty for most files. However, the situation gets uglier as the size of your versioned files grows. Some attention is being given to making the presence of the “text-base” an option. Ironically, though, it is as your versioned files' sizes get larger that the existence of the “text-base” becomes more crucial—who wants to transmit a huge file across a network just because she wants to commit a tiny change to it?

Similar in purpose to the “text-base” files are the property files and their pristine “prop-base” copies, located in .svn/props and .svn/prop-base, respectively. Since directories can have properties too, there are also .svn/dir-props and .svn/dir-prop-base files.

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 .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 version grandissent. Nous étudions dorénavant la possibilité de rendre optionnel la présence de ces fichiers "versions de base". Cependant, c'est justement quand vos fichiers suivis en version grandissent que l'existence de fichiers "versions de base" devient cruciale — qui veut 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.