Perhaps the single most important file in the .svn directory is the entries file. The entries file is an XML document which contains the bulk of the administrative information about a versioned resource in a working copy directory. It is this one file which 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!

Forse il più importante singolo file nella directory .svn è il file entries. Il file entries è un documento XML che contiene la massa delle informazioni amministrative circa le risorse versionate in una directory della copia di lavoro. È questo il file che traccia gli URL del repository, revisioni originarie, il checksum dei file, testo originario e la proprietà timestamp, le informazioni di pianificazione e di stato di conflitto, informazioni sull'ultimo commit fatto (autore, revisione, timestamp), lo storico della copia locale—praticamente ogni cosa che un client di Subversion è interessato a sapere circa le risorse versionate (o da versionare)!

The following is an example of an actual entries file:

Il seguente è un esempio degli elementi file reali:

<?xml version="1.0" encoding="utf-8"?>
<wc-entries
   xmlns="svn:">
<entry
   committed-rev="1"
   name=""
   committed-date="2005-04-04T13:32:28.526873Z"
   url="http://svn.red-bean.com/repos/greek-tree/A/D"
   last-author="jrandom"
   kind="dir"
   uuid="4e820d15-a807-0410-81d5-aa59edf69161"
   revision="1"/>
<entry
   name="lambda"
   copied="true"
   kind="file"
   copyfrom-rev="1"
   schedule="add"
   copyfrom-url="http://svn.red-bean.com/repos/greek-tree/A/B/lambda"/>
<entry
   committed-rev="1"
   name="gamma"
   text-time="2005-12-11T16:32:46.000000Z"
   committed-date="2005-04-04T13:32:28.526873Z"
   checksum="ada10d942b1964d359e048dbacff3460"
   last-author="jrandom"
   kind="file"
   prop-time="2005-12-11T16:32:45.000000Z"/>
<entry
   name="zeta"
   kind="file"
   schedule="add"
   revision="0"/>
<entry
   name="G"
   kind="dir"/>
<entry
   name="H"
   kind="dir"
   schedule="delete"/>
</wc-entries>

As you can see, the entries file is essentially a list of entries. Each entry tag represents one of three things: the working copy directory itself (called the “this directory” entry, and noted as having an empty value for its name attribute), a file in that working copy directory (noted by having its kind attribute set to "file"), or a subdirectory in that working copy (kind here is set to "dir"). The files and subdirectories whose entries are stored in this file are either already under version control, or (as in the case of the file named zeta above) are scheduled to be added to version control when the user next commits this working copy directory's changes. Each entry has a unique name, and each entry has a node kind.

Come si può vedere, il file entries è essenzialmente una lista di entrate. Ogni etichetta entry rappresenta una di tre cose: la directory della copia di lavoro stessa (chiamata l'entrata «questa directory», e famosa per avere valore vuoto per il suo attributo name), un file in questa directory della copia di lavoro (famosa per avere il suo attributo kind impostato a "file"), o una sottodirectory in questa copia di lavoro (qui kind è impostato a "dir"). I file e lo sottodirectory per i quali le entrate sono immagazzinate in questo file sono o già sotto controllo di versione, o (come nel caso del file sopra di nome zeta) sono pianificato per essere aggiunte al controllo di versione quando l'utente farà il prossimo commit dei cambiamente a questa directory della copia di lavoro. Ogni entrata ha un nome univoco, e ogni entrata ha un nodo kind.

Developers should be aware of some special rules that Subversion uses when reading and writing its entries files. While each entry has a revision and URL associated with it, note that not every entry tag in the sample file has explicit revision or url attributes attached to it. Subversion allows entries to not explicitly store those two attributes when their values are the same as (in the revision case) or trivially calculable from ^[71] (in the url case) the data stored in the “this directory” entry. Note also that for subdirectory entries, Subversion stores only the crucial attributes—name, kind, url, revision, and schedule. In an effort to reduce duplicated information, Subversion dictates that the method for determining the full set of information about a subdirectory is to traverse down into that subdirectory, and read the “this directory” entry from its own .svn/entries file. However, a reference to the subdirectory is kept in its parent's entries file, with enough information to permit basic versioning operations in the event that the subdirectory itself is actually missing from disk.

Gli sviluppatori dovrebbero fare attenzione ad alcune regole speciali che Subversion utilizza quando legge e scrive i propri file entries. Mentre ogni entrata ha una revisione e un URL associati ad essi, notare che non ogni etichetta entry nel file di esempio ha specifici attributi revision o url allegati a esso. Subversion permette alle entrate di non immagazzinare esplicitamente questi due attributi quando il loro valoro è lo stesso (nel caso revision) o banalmente calcolabile da ^[72] (nel caso url) i dati immagazzinati nell'entrata «questa directory». Notare anche che per entrate sottodirectory, Subversion immagazzina solamente gli attributi cruciali—name, kind, url, revision, e schedule. In uno sforzo di ridurre informazioni duplicate, Subversion impone il metodo per determinare l'insieme completo delle informazioni circa una sottodirectory è di traversare verso il basso all'interno di questa sottodirectory, e leggere l'entrata «questa directory» dal suo file .svn/entries. Tuttavia, un riferimento alla sottodirectory è tenuto nel file entries della directory superiore, con abbastanza informazioni da permettere operazioni di versionamento di base nel caso in cui la sottodirectory stessa attualmente manchi dal disco.

As mentioned before, the .svn directory also holds the pristine “text-base” versions of files. Those can be found 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, smaller transmission of changes to the server—but comes 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 they want to commit a tiny change to it?

Come menzionato prima, la directory .svn contiene anche le versioni «testuali» originarie dei file. Questi possono essere trovati in .svn/text-base. I benefici di queste copie originarie sono multiple—controlli liberi dalla rete per modifiche locali e differenze, revisione libera dalla rete di file modificati o mancanti, trasmissioni più piccole di cambiamenti al server—ma vengono al costodi avere ogni file versionato immagazzinato almeno due volte sul disco. Ai giorni nostri, questo sembra essere una penalità trascurabile per la maggior parte dei file. Tuttavia, la situazione diventa più sgradevole se la dimensione dei propri file versionati aumenta. Qualche attenzione deve essere fatta sul fare della presenza di «text-base» un'opzione. Benché ironicamente, come le dimensioni dei propri file versionati diventa più grande l'esistenza di «text-base» diventa maggiormente cruciale—che vuole trasmettere un file enorme sulla la rete solo perché vuole fare un commit di un piccolo cambiamento a questo?

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. Each of these property files (“working” and “base” versions) uses a simple “hash-on-disk” file format for storing the property names and values.

Simile nello scopo dei file in «text-base» sono i file proprietà e le loro copie originarie «prop-base», posizionati rispettivamente in .svn/props e .svn/prop-base. Dato che le directory possono avere anche le proprietà, ci sono anche i file .svn/dir-props e .svn/dir-prop-base. Ognuno di questi file di proprietà (versioni «working» e «base») utilizza un semplice formato di file «hash-on-disk» per immagazzinare i nomi delle proprietà e i valori.