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 archivos. Puede editar estos archivos como desee, y si son archivos de código fuente, puede compilar su programa de la forma habitual. Su copia de trabajo es su á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 que haya hecho algunos cambios en los archivos dentro de su copia de trabajo y haya verificado que funcionan correctamente, Subversion le provee de comandos para publicar sus cambios para los 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 ayudar a llevar a cabo estos comandos. En particular, tu copia de trabajo contiene un subdirectorio llamado .svn, también conocido como el directorio administrativo de la copia de trabajo. Los ficheros en este directorio administrativo ayudan a Subversion a reconocer qué ficheros contienen cambios no publicados, y qué ficheros contienen contenidos desfasados respecto a otros de trabajo. Antes de Subversion 1.7 existían subdirectorios administrativos .svn en cada directorio versionado de tu copia de trabajo. Subversion 1.7 se comporta de manera diferente, usando un único subdirectorio dependiente del root de la copia de trabajo.
Un repositorio típico de Subversion a menudo contiene los archivos (o el código fuente) de varios proyectos; usualmente, cada proyecto es un subdirectorio en el árbol de archivos 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, debes desproteger algún subárbol del repositorio. (El término desprotegerouuede sonar como que tuviera algo que hacer con bloqueos o recursos, pero no es necessrio; simplemente crea una copua privada del proyecto para tí.)
Suponga que ha hecho cambios a button.c. Dado que el directorio .svn recuerda la fecha de modificación y los contenidos originales del archivo, Subversion puede decirle que ha cambiado dicho archivo. 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á sus cambios en la última versión del archivo.
Suponga que tiene un colaborador, Sally, quien 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é archivos actualizar; Subversion utiliza la información en el directorio .svn, y más información desde el repositorio, para decidir qué archivos 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, 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:/path/to/repos
...
file:///X|/path/to/repos
...
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 a un repositorio FSFS utilizando una carpeta compartida de red, pero no es recomendable por varias razones:
Usted está dando permisos de escritura a todos los usuarios, así ellos pueden accidentalmente eliminar o corromper el repositorio del systema.
No todos los protocolos de compartición de ficheros soportan el bloqueo que Subversion requiere. Un día se encontrará su repositorio tendrá el subtítulo de corrupto.
Usted tiene que establecer los permisos de acceso del modo correcto. SAMBA es particularmente complicado a este respecto.
Si una persona instala una versión más moderna del cliente que modifica el formato del repositorio, entonces todo el mundo no podrá acceder al repositorio hasta que se actualicen el clliente a la nueva versión.
Una operación svn commit puede publicar los cambios de cualquier número de archivos y carpetas como una única transacción atómica. En su copia de trabajo, puede cambiar el contenido de los archivos, crear, borrar, renombrar y copiar archivos 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 archivos, 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 archivos 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 archivo 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 confirma 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 que haga una actualización limpia en la parte superior de su copia de trabajo, generalmente corresponderá exactamente una revisión del repositorio.
Por cada archivo en un directorio de trabajo, Subversion grabará dos piezas esenciales de información en el área administrativa .svn/:
qué número de revisión tiene su fichero de trabajo ( esto es llamado la revisión de trabajo del fichero), 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 archivo de trabajo:
- Sin cambios, y actualizado
El archivo no se ha cambiado en el directorio de trabajo, y no se han confirmado cambios a ese archivo en el repositorio desde su revisión de trabajo. Una confirmación de ese archivo no hará nada, y una actualización de ese archivo no hará nada.
- Cambiado localmente, y actualizado
El archivo ha sido cambiado en el directorio de trabajo, y no se ha confirmado ningún cambio a ese archivo 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 archivo se conseguirá publicar sus cambios, y al actualizar el archivo no se realizará nada.
- Sin cambios, y desactualizado
El archivo no ha sido cambiado en el directorio de trabajo, pero ha sido cambiado en el repositorio. El archivo deberá ser actualizado en algún momento, para actualizarlo con la revisión pública. Un comando confirmar sobre el archivo no hará nada, y al actualizar el archivo se traerán los últimos cambios a su copia de trabajo.
- Cambiado localmente, y desactualizado
El archivo se ha cambiado tanto en el directorio de trabajo como en el repositorio. Un comando confirmar sobre el archivo fallará con un error desactualizado. El archivo 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.