Quizás el fichero más importante en el directorio .svn es el fichero entries. El fichero de entradas es un documento XML que contiene el grueso de la información administrativa sobre un recurso versionado en el directorio de la copia local de trabajo. Es el fichero que lleva la pista a las URLs de repositorio, revisiones prístinas, sumas de control de ficheros, textos prístinos y fechas de modificación de propiedades, información de planificación y estado de conflicto, última información conocida de cambios en el repositorio (autor, revisión, fecha de modificación), historia de la copia local—¡prácticamente todo lo que un cliente de Subversion puede estar interesado en saber sobre un recurso versionado (o por versionar)!

A continuación mostramos un ejemplo de un fichero de entradas real:

<?xml version="1.0" encoding="utf-8"?>
<wc-entries
   xmlns="svn:">
<entry
   committed-rev="1"
   name="svn:this_dir"
   committed-date="2002-09-24T17:12:44.064475Z"
   url="http://svn.red-bean.com/tests/.greek-repo/A/D"
   kind="dir"
   revision="1"/>
<entry
   committed-rev="1"
   name="gamma"
   text-time="2002-09-26T21:09:02.000000Z"
   committed-date="2002-09-24T17:12:44.064475Z"
   checksum="QSE4vWd9ZM0cMvr7/+YkXQ=="
   kind="file"
   prop-time="2002-09-26T21:09:02.000000Z"/>
<entry
   name="zeta"
   kind="file"
   schedule="add"
   revision="0"/>
<entry
   url="http://svn.red-bean.com/tests/.greek-repo/A/B/delta"
   name="delta"
   kind="file"
   schedule="add"
   revision="0"/>
<entry
   name="G"
   kind="dir"/>
<entry
   name="H"
   kind="dir"
   schedule="delete"/>
</wc-entries>

Tal y como puede ver, el fichero entries es esencialmente una lista de entradas. Cada etiqueta entry representa una de tres posibles cosas: el propio directorio de la copia local (entrada conocida como “este directorio”, y caracterizada por tener un valor vacío para su atributo name), un fichero en esa copia local (caracterizado por tener en su atributo kind el valor "file"), o un subdirectorio en esa copia local (kind en este caso tendrá el valor "dir"). Los ficheros y subdirectorios cuyas entradas ya están almacenadas en este fichero están o bien bajo control de versiones, o (como en el caso del fichero zeta más arriba) están programados para ser puestos bajo control de versiones la siguiente vez que el usuario envíe los cambios de este directorio al repositorio. Cada entrada tiene un nombre único, y cada entrada es de tipo nodo .

Los desarrolladores deben tener presentes algunas reglas especiales que Subversion usa cuando lee y escribe sus ficheros entries. Aunque cada entrada tiene asociada una revisión y URL, fíjese que no toda etiqueta entry en el fichero de ejemplo tiene un atributo revision o url asociado a ella. Subversion permite que las entradas no almacenen explícitamente esos dos atributos cuando sus valores son iguales que (en el caso de revision) o triviales de calcular a partir de ^[49] (en el caso de url) los datos almacenados en la entrada “este directorio”. Tenga también en cuenta que para las entradas de subdirectorios, Subversion almacena únicamente los atributos cruciales—nombre, tipo, url, revisión, y acción programada. En un esfuerzo para reducir información duplicada, Subversion dicta que el método para determinar el conjunto completo de información sobre un subdirectorio es descender dentro de ese subdirectorio, y leer la entrada “este directorio” de su propio fichero .svn/entries. No obstante, se mantiene una referencia al subdirectorio en el fichero entries del padre, con suficiente información para permitir operaciones básicas de versionado en el evento de que el propio subdirectorio no esté presente en el disco.

Tal y como mencionamos anteriormente, el directorio .svn también contiene versiones “text-base” prístinas de los ficheros. Éstas pueden encontrarse en .svn/text-base. Los beneficios de estas copias son múltiples—evitan conexiones por red cuando se quiere saber si hay modificaciones locales y qué es lo que ha cambiado, permiten revertir ficheros modificados o eliminados, los cambios que se transmiten al servidor son menores—pero hay que pagar el precio de almacenar cada fichero versionado dos veces en el disco. Hoy en día, esto parece una desventaja despreciable para la mayoría de los ficheros. No obstante, esta situación se vuelve más delicada a medida que el tamaño de sus ficheros versionados crece. Se está prestando atención para permitir que la presencia de “text-base” sea una opción. Pero irónicamente, es a medida que los tamaños de sus ficheros versionados crecen cuando la existencia de “text-base” se vuelve más crucial—¿quién quiere transmitir un fichero enorme por red sólo porque quieren realizar una pequeña modificación sobre el mismo?

Con un propósito similar a los ficheros “text-base” existen los ficheros de propiedades y sus copias “prop-base” prístinas, encontradas en .svn/props y .svn/prop-base respectivamente. Dado que los directorios también pueden tener propiedades, también existen los ficheros .svn/dir-props y .svn/dir-prop-base. Cada uno de estos ficheros de propiedades (versiones “base” y “en desarrollo”) usan un simple fichero de formato “hash-on-disk” para almacenar los nombres de las propiedades y sus valores.