Ya ha oído hablar sobre las copias de trabajo; ahora le demostraremos cómo las crea y las utiliza el cliente de Subversion.
Una copia de trabajo de Subversion es un árbol de directorios ordinario en su sistema local, conteniendo una colección de ficheros. Puede editar estos ficheros como desee, y si son ficheros de código fuente, puede compilar su programa de la forma habitual. Su copia de trabajo es su propia área de trabajo privada: Subversion nunca incorporará los cambios de otra gente, ni hará que sus cambios estén disponibles para los demás, a menos que se lo pida explícitamente.
Después de que haya hecho algunos cambios en los ficheros dentro de su copia de trabajo y haya verificado que funcionan correctamente, Subversion le provee de comandos para publicar sus cambios para los demás que trabajan con usted en su proyecto (escribiendo en el repositorio). Si los demás publican sus propios cambios, Subversion le provee de comandos para fusionar esos cambios dentro de su copia de trabajo (leyendo desde el repositorio).
Una copia de trabajo también contiene algunos ficheros extra, creados y mantenidos por Subversion, para ayudarse a llevar a cabo esos comandos. En particular, cada directorio detnro de su copia de trabajo contiene un subdirectorio llamado .svn, también conocido como el directorio administrativo de la copia de trabajo. Los ficheros dentro de los directorios administrativos ayudan a Subversion a reconocer qué ficheros contienen cambios no publicados, y qué ficheros están desactualizados respecto al trabajo de los demás.
Un repositorio típico de Subversion a menudo contiene los ficheros (o el código fuente) de varios proyectos; usualmente, cada proyecto es un subdirectorio en el árbol de ficheros del repositorio. Con esta disposición, una copia de trabajo de un usuario normalmente corresponderán a un subárbol particular del repositorio.
Por ejemplo, suponga que tiene un repositorio que contiene dos proyectos de software.
En otras palabras, el directorio raíz del repositorio tiene dos subdirectorios, paint y calc.
Para obtener una copia de trabajo, primero debe obtener algún subárbol del repositorio. (El término obtener puede sonar como que tenga algo que ver con el bloqueo o la reserva de recursos, pero no es cierto; simplemente crea una copia privada del proyecto para usted).
Suponga que ha hecho cambios a button.c. Dado que el directorio .svn recuerda la fecha de modificación y los contenidos originales del fichero, Subversion puede decirle que ha cambiado el fichero. Sin embargo, Subversion no hace públicos sus cambios hasta que explícitamente se lo pida. El acto de publicar sus cambios se conoce más comúnmente como confirmar (o enviar) los cambios al repositorio.
Para publicar sus cambios para los demás, puede utilizar el comando de Subversion commit.
Ahora que sus cambios a button.c se han confirmado en el respositorio, si cualquier otro usuario obtiene una copia de trabajo de /calc, verán sus cambios en la última versión del fichero.
Suponga que tiene un colaborador, Sally, que obtuvo una copia de trabajo de /calc al mismo tiempo que usted. Cuando ha confirmado sus cambios en button.c, la copia de trabajo de Sally se queda sin cambios; Subversion sólo modifica las copias de trabajo cuando lo pide el usuario.
Para poner al día su proyecto, Sally puede pedirle a Subversion actualizar su copia de trabajo, utilizando el comando de Subversion actualizar. Esto incorporará sus cambios en la copia de trabajo de Sally, junto con cualquier otro que se haya confirmado desde que ella lo obtuvo.
Tenga en cuenta que Sally no necesita especificar qué ficheros actualizar; Subversion utiliza la información en el directorio .svn, y más información desde el repositorio, para decidir qué ficheros deben ponerse al día.
Los repositorios de Subversion pueden ser accedidos por muchos métodos diversos - en discos locales, o a través de varios protocolos de red. La ruta de un repositorio es siempre, sin embargo, una URL. El esquema URL indica el método de acceso:
Tabla 2.1. URLs de acceso al repositorio
| Esquema | Método de acceso |
|---|---|
file://
| Acceso directo al repositorio en el disco local o de red. |
http://
| Acceso utilizando el protocolo WebDAV a un servidor Apache configurado para Subversion. |
https://
| Lo mismo que http://, pero con encriptación SSL. |
svn://
| Acceso TCP/IP sin autentificación utilizando un protocolo personalizado a un servidor svnserve. |
svn+ssh://
| Acceso TCP/IP autentificado y encriptado utilizando un protocolo propio a un servidor svnserve. |
En su mayoría, las URLs de Subversion utilizan la sintaxis estándar, permitiendo que se especifiquen nombres de servidor y números de puertos como parte de la URL. El método de acceso file:// se utiliza normalmente para el acceso local, aunque puede utilizarse con rutas UNC a equipos en red. La URL por lo tanto toma la forma file://nombredeequipo/ruta/al/repositorio. Para la máquina local, la parte nombredeequipo de la URL debe estar o ausente o ser localhost. Por esta razón, las rutas locales normalmente aparecen con tres barras, file:///ruta/al/repositorio.
Además, los usuarios del esquema file:// en las plataformas Windows necesitarán utilizar una sintaxis “estándar” no oficial para acceder a los repositorios que están en la misma máquina, pero en una letra de unidad diferente de la unidad actual del cliente. Cualquiera de las siguientes sintaxis de URL funcionarán, donde X es la unidad en la que reside el repositorio:
file:///X:/ruta/al/repositorio ... file:///X|/ruta/al/repositorio ...
Tenga en cuenta que las URLs utilizan las barras hacia delante (las de dividir) incluso aunque la forma nativa (no-URL) de una ruta en Windows utiliza las barras contrarias.
Puede acceder con seguridad a un repositorio FSFS utilizando una carpeta compartida de red, pero no puede acceder a un repositorio BDB de esta forma.
Aviso
No cree o acceda a un repositorio Berkeley DB en una unidad de red compartida. No puede existir en un sistema de archivos remoto. Ni siquiera si tiene la unidad de red mapeada a una letra de unidad. Si intenta usar Berkeley DB en una unidad de red compartida, los resultados son imprevisibles - puede ver desde el principio errores misteriosos, o pueden pasar meses antes de que descubra que su base de datos del repositorio está corrupta de una forma inimaginable.
Una operación svn commit puede publicar los cambios de cualquier número de ficheros y carpetas como una única transacción atómica. En su copia de trabajo, puede cambiar el contenido de los ficheros, crear, borrar, renombrar y copiar ficheros y directorios, y luego confirmar el conjunto completo de cambios como una unidad.
En el repositorio, cada confirmación se trata como una transacción atómica: o bien todos los cambios de la confirmación se llevan a cabo, o bien ninguno de ellos se realiza. Subversion aplica esta atomicidad en caso de errores en el programa, errores del sistema, problemas de red, y otras acciones del usuario.
Cada vez que el repositorio acepta una confirmación, crea un nuevo estado del árbol de ficheros, llamado revisión. A cada revisión se le asigna un número natural único, un número mayor que la revisión anterior. La revisión inicial de un repositorio recién creado se numera como cero, y consiste únicamente en un directorio raíz vacío.
Una buena forma de visualizar el repositorio es como una serie de árboles. Imagine una fila de números de revisiones, empezando en 0, de izquierda a derecha. Cada número de revisión tiene un árbol colgando debajo, y cada árbol es una “foto” de cómo estaba el repositorio tras cada confirmación.
Es importante que tenga en cuenta que las copias de trabajo no siempre se corresponden a una única revisión en el repositorio; pueden contener ficheros de varias revisiones.Por ejemplo, suonga que obtiene una copia de trabajo de un repositorio cuya revisión más reciente es la 4:
calc/Makefile:4
integer.c:4
button.c:4
En este momento, esta copia de trabajo corresopnde exactamente a la revisión 4 en el respositorio. Sin embargo, suponga que ha hecho cambios al fichero button.c, y confirme ese cambio. Asumiendo que no se haya llevado a cambio ninguna otra confirmación, su confirmación creará la revisión 5 en el repositorio, y su copia de trabajo quedará así:
calc/Makefile:4
integer.c:4
button.c:5
Suponga que, en este punto, Sally hace un cambio a integer.c, creando la revisión 6. Si utiliza svn update para actualizar su copia de trabajo, obtendrá ésto:
calc/Makefile:6
integer.c:6
button.c:6
Los cambios de Sally a integer.c aparecerán en su copia de trabajo, y su cambio estará aún presente en button.c. En este ejemplo, el texto de Makefile es idéntico en las revisiones 4, 5, y 6, pero Subversion marcará su copia de trabajo de Makefile con la revisión 6 para indicar que aún está actualizado. Por lo que, después de que haga una actualización limpia en la parte superior de su copia de trabajo, generalmente obtendrá exactamente una revisión del repositorio.
Por cada fichero en un directorio de trabajo, Subversion grabará dos piezas esenciales de información en el área administrativa .svn/:
en qué revisión se basa su fichero de trabajo (lo que se denomina la revisión de trabajo), y
una fecha que indica cuándo se actualizó por última vez la copia local por el repositorio.
Con esta información, hablando con el repositorio, Subversion puede decirle en cuál de los siguientes cuatro estados está un fichero de trabajo:
- Sin cambios, y actualizado
El fichero no se ha cambiado en el directorio de trabajo, y no se han confirmado cambios a ese fichero en el repositorio desde su revisión de trabajo. Una confirmación de ese fichero no hará nada, y una actualización de ese fichero no hará nada.
- Cambiado localmente, y actualizado
El fichero ha sido cambiado en el directorio de trabajo, y no se ha confirmado ningún cambio a ese fichero en el repositorio desde su revisión base. Hay cambios locales que no se han confirmado en el repositorio, por lo que al confirmar el fichero se conseguirá publicar sus cambios, y al actualizar el fichero no se realizará nada.
- Sin cambios, y desactualizado
El fichero no ha sido cambiado en el directorio de trabajo, pero ha sido cambiado en el repositorio. El fichero deberá ser actualizado en algún momento, para actualizarlo con la revisión pública. Un comando confirmar sobre el fichero no hará nada, y al actualizar el fichero se traerán los últimos cambios a su copia de trabajo.
- Cambiado localmente, y desactualizado
El fichero se ha cambiado tanto en el directorio de trabajo como en el repositorio. Un comando confirmar sobre el fichero fallará con un error desactualizado. El fichero debería actualizarse primero; al actualizar se intentará fusionar los cambios públicos con los cambios locales. Si Subversion no puede completar la fusión de una forma plausible automáticamente, le dejará al usuario la tarea de resolver el conflicto.