Ciclo básico de trabajo

Subversion tiene numerosas características, opciones, campanas y silbidos, pero bajo uso cotidiano lo más probable es que use solamente algunas de ellas. En esta sección veremos las cosas más comunes que usted puede encontrarse haciendo con Subversion en el transcurso de un día de trabajo.

El ciclo de trabajo típico se parece a esto:

Actualizar su copia de trabajo local

Cuando se trabaja en un proyecto con un equipo, usted querrá actualizar su copia de trabajo local para recibir cualquier cambio hecho desde su última actualización por otros desarrolladores en el proyecto. Use svn update para poner a su copia de trabajo local en sincronía con la última revisión en el repositorio.

$ svn update
U  foo.c
U  bar.c
Updated to revision 2.

En este caso, alguien envió modificaciones a foo.c y bar.c desde la última vez que usted actualizó, y Subversion ha actualizado su copia de trabajo local para incluir estos cambios.

Vamos a examinar la salida de svn update un poco más. Cuando el servidor envía cambios a su copia de trabajo local, un código de letras es mostrado al lado de cada elemento para hacerle saber qué acciones realizó Subversion para actualizar su copia de trabajo local:

U foo

El fichero foo fue actualizado[6] (recibidos cambios del servidor).

A foo

El fichero o directorio foo fue Añadido a su copia de trabajo local.

D foo

El fichero o directorio foo fue borrado [7] de su copia de trabajo local.

R foo

El fichero o directorio foo fue Reemplazado en su copia de trabajo local; esto es, foo fue borrado, y un nuevo objeto con el mismo nombre fue añadido. Aunque pueden tener el mismo nombre, el repositorio los considera objetos distintos con historiales distintos.

G foo

El fichero foo recibió nuevos cambios del repositorio, pero su copia local del fichero tenía las modificaciones que ud. ya había hecho. O los cambios no se intersectaron , o los cambios eran exactamente iguales que sus modificaciones locales, así que Subversion ha fusionado [8] satisfactoriamente los cambios del repositorio en el fichero sin ningún problema.

C foo

El fichero foo recibió cambios Conflicting del servidor. Los cambios del servidor directamente se superpusieron sobre sus propios cambios en el fichero. Aunque no hay necesidad de aterrarse. Esta superposición necesita ser resuelta por un humano (usted); tratamos esta situación más tarde en este capítulo.

Hacer cambios en su copia de trabajo local

Ahora puede conseguir trabajar y hacer cambios en su copia de trabajo local. Generalmente es más conveniente decidir un cambio particular (o un conjunto de cambios) a hacer, por ejemplo escribir una nueva característica, corregir un fallo, etc. Los comandos de Subversion que puede usar aquí son svn add, svn delete, svn copy, y svn move. Sin embargo, si usted está simplemente corrigiendo los archivos que están ya en Subversion, puede no necesitar utilizar ninguno de estos comandos hasta que envíe los cambios. Cambios que puede hacer a su copia de trabajo local:

Cambios en los ficheros

Esta es la clase más simple de cambio. No necesita decirle a Subversion que se propone a cambiar un fichero; simplemente haga los cambios. Subversion será capaz de detectar automáticamente qué archivos han sido cambiados.

Cambios en el árbol

Puede preguntar a Subversion que marque ficheros y directorios para el borrado planificado, la adición, la copia, o moverlos. Mientras estos cambios pueden ocurrir inmediatamente en su copia de trabajo local, ninguna adición o borrado sucederá en el repositorio hasta que envíe los cambios.

Para hacer cambios en los ficheros, use su editor de textos, procesador de textos, programa de gráficos , o cualquier herramienta que usaría normalmente. Subversion maneja ficheros binarios tan fácilmente como maneja archivos de texto—y tan eficientemente también.

Aquí hay una descripción de los cuatro subcomandos de Subversion que usted usará más a menudo para hacer cambios del árbol (cubriremos svn import y svn mkdir después.

svn add foo

Programa añadir foo al repositorio. Cuando haga su próximo envío, foo se convertirá en hijo de su directorio padre. Fíjese que si foo es un directorio, todo por debajo de foo será programado para la adición . Si solo quiere añadir el propio foo, pase la opción --non-recursive (-N) .

svn delete foo

Programa borrar foo del repositorio. Si foo es un fichero, se borrará inmediatamente de su copia de trabajo local. Si foo es un directorio, este no es borrado, pero Subversion lo programa para borrarlo. Cuando envíe sus cambios, foo será borrado de su copia de trabajo y del repositorio.[9]

svn copy foo bar

Crea un nuevo objeto bar como duplicado de foo. bar es automáticamente programado para la adición. Cuando bar es añadido al repositorio en el siguiente envío de cambios, su historia de copia es registrada (como que originalmente viene de foo).svn copy no crea directorios intermedios.

svn move foo bar

Este comando funciona exactamente igual que svn copy foo bar; svn delete foo. Esto es, se programa bar para la adición como una copia de foo, y se programa foo para la eliminación. svn move no crea directorios intermedios.

Examine sus cambios

Una vez que haya terminado de hacer cambios, necesita enviarlos al repositorio, pero antes de hacerlo, generalmente es buena idea echar un vistazo a lo que ha cambiado exactamente. Examinando sus cambios antes de que los envíe, puede hacer un mensaje de informe de cambios más exacto. También puede descubrir que ha cambiado inadvertidamente un fichero, y esto le da la posibilidad de invertir esos cambios antes de enviarlos. Además, esta es una buena oportunidad para revisar y escudriñar cambios antes de publicarlos. Usted puede ver exactamente qué cambios ha hecho usando svn status, svn diff, y svn revert. Generalmente usará los primeros dos comandos para descubrir qué ficheros han cambiado en su copia de trabajo local, y después quizá el tercero para invertir algunos (o todos) de esos cambios.

Subversion ha sido optimizado para ayudarle con esta tarea, y es capaz de hacer muchas cosas sin comunicarse con el repositorio. En particular, su copia de trabajo local contiene una copia prístina secreta almacenada de cada fichero de versión controlado dentro del área .svn. Debido a esto, Subversion puede rápidamente mostrarle cómo sus ficheros de trabajo han cambiado, o incluso permitirle deshacer sus cambios sin contactar con el repositorio.

svn status

Probablemente usará el comando svn status más que cualquier otro comando de Subversion.

Si ejecuta svn status en lo alto de su copia de trabajo sin argumentos, detectará todos los cambios de fichero y árbol que usted ha hecho. Este ejemplo está diseñado para mostrar todos los códigos de estado diferentes que svn status puede devolver. (Observe que el texto que sigue a # en el siguiente ejemplo no es impreso realmente por svn status.)

$ svn status
  L    abc.c               # svn has a lock in its .svn directory for abc.c
M      bar.c               # the content in bar.c has local modifications
 M     baz.c               # baz.c has property but no content modifications
X      3rd_party           # this dir is part of an externals definition
?      foo.o               # svn doesn't manage foo.o
!      some_dir            # svn manages this, but it's either missing or incomplete
~      qux                 # versioned as dir, but is file, or vice versa
I      .screenrc           # this file is ignored
A  +   moved_dir           # added with history of where it came from
M  +   moved_dir/README    # added with history and has local modifications
D      stuff/fish.c        # this file is scheduled for deletion
A      stuff/loot/bloo.h   # this file is scheduled for addition
C      stuff/loot/lump.c   # this file has conflicts from an update
    S  stuff/squawk        # this file or dir has been switched to a branch
…

En este formato de salida svn status impresa cinco columnas de caracteres, seguidos por varios caracteres de espacio en blanco, seguido por un nombre de fichero o directorio. La primera columna dice el estado de un fichero o directorio y/o su contenido. Los códigos impresos aquí son:

A file_or_dir

El fichero o directorio file_or_dir ha sido programado para la adición en el repositorio.

C file

El fichero file está en un estado de conflicto. Esto es, los cambios recibidos del servidor durante una actualización se solapan con cambios locales que usted tiene en su copia de trabajo. Debe resolver este conflicto antes de enviar sus cambios al repositorio.

D file_or_dir

El fichero o directorio file_or_dir ha sido programado para la supresión del repositorio.

M file

El contenido del fichero file ha sido modificado.

X dir

El directorio dir está sin versionar, pero está relacionado con una definición externa de Subversion. Para descubrir más acerca de definiciones externas, vea “Repositorios externos”.

? file_or_dir

El fichero o directorio file_or_dir no está bajo control de versiones. Puede silenciar la marca de pregunta pasando la opción --quiet (-q) a svn status, o o poniendo la característica svn:ignore en el directorio padre. Para más información sobre ficheros ignorados, vea svn:ignore.

! file_or_dir

El fichero o directorio file_or_dir está bajo el control de versiones pero falta o está de alguna manera incompleto. El objeto puede faltar si se ha borrado usando un comando ajeno a Subversion. En el caso de un directorio, puede estar incompleto si ha interrumpido una descarga o una actualización. Un rápido svn update repondrá el fichero o el directorio desde el repositorio, o svn revert file restaurará un archivo que falta.

~ file_or_dir

El fichero o directorio file_or_dir está en el repositorio como un tipo de objeto, pero actualmente está en su copia de trabajo como otro tipo. Por ejemplo, Subversion pudo tener un fichero en el repositorio, pero usted borró el fichero y creó un directorio en su lugar, sin usar los comandos svn delete o svn add.

I file_or_dir

Subversion está ignorando el fichero o directorio file_or_dir, probablemente porque usted se lo dijo. Para más información sobre ficheros ignorados, vea svn:ignore. Observe que este símbolo solo aparece si le pasa la opción --no-ignore a svn status.

La segunda columna dice el estado de las propiedades de un fichero o un directorio (vea “Propiedades” para más información sobre propiedades). Si aparece una M en la segunda columna, entonces las propiedades han sido modificadas, si no un espacio en blanco será impreso.

La tercera columna solo mostrará un espacio en blanco o una L la cual significa que Subversion ha bloqueado el objeto en el área de trabajo .svn. Usted verá una L si ejecuta svn status en un directorio donde un svn commit esté en progreso—quizás cuando esté editando el informe de cambios. Si Subversion no se está ejecutando, entonces probablemente Subversion fue interrumpido y el bloqueo necesita ser eliminado ejecutando svn cleanup (más sobre eso más adelante en este capítulo).

La cuarta columna solo mostrará un espacio blanco o un + el cual significa que el fichero o directorio está programado para ser añadido o modificado con historial adicional adjunto. Esto ocurre típicamente cuando usted svn move o svn copy un fichero o directorio. Si usted ve A  +, esto significa que el objeto está programado para la adición-con-historial. Este puede ser un fichero, o la raíz de un directorio copiado. + significa que el objeto es parte de un subárbol programado para la adición-con-historial, p.e.algún padre fue copiado,and it's just coming along for the ride. M  + significa que el objeto es parte de un subárbol programado para la adición-con-historial, y este tiene modificaciones locales. Cuando envíe los cambios, primero el padre será añadido-con-historial (copiado), lo que significa que este fichero existirá automáticamente en la copia. Entonces las modificaciones locales serán enviadas al repositorio.

La quinta columna solo mostrará un espacio en blanco o una S. Esto significa que el fichero o directorio ha sido movido de la ruta del resto de la copia de trabajo (usando svn switch) a una rama.

Si usted pasa una ruta específica a svn status, este le dará información acerca de ese objeto solamente:

$ svn status stuff/fish.c
D      stuff/fish.c

svn status también tiene una opción --verbose (-v), el cuál le mostrará el estado de todos los objetos en su copia de trabajo, incluso si este no ha sido cambiado:

$ svn status --verbose
M               44        23    sally     README
                44        30    sally     INSTALL
M               44        20    harry     bar.c
                44        18    ira       stuff
                44        35    harry     stuff/trout.c
D               44        19    ira       stuff/fish.c
                44        21    sally     stuff/things
A                0         ?     ?        stuff/things/bloo.h
                44        36    harry     stuff/things/gloo.c

Esta es la forma larga de salida de svn status. La primera columna permanece igual, pero la segunda columna muestra la revisión de trabajo del fichero. La tercera y cuarta columna muestra la revisión en la cuál el objeto cambió por última vez, y quién lo cambió.

Ninguna de las invocaciones anteriores a svn status contactaban con el repositorio, trabajan solo localmente comparando los metadatos en el directorio .svn con la copia de trabajo local. Finalmente está la opción --show-updates (-u), la cual contacta con el repositorio y añade información acerca de las cosas que están fuera-de-fecha:

$ svn status --show-updates --verbose
M      *        44        23    sally     README
M               44        20    harry     bar.c
       *        44        35    harry     stuff/trout.c
D               44        19    ira       stuff/fish.c
A                0         ?     ?        stuff/things/bloo.h
Status against revision:   46

Observe los dos asteriscos: si usted ejecutara svn update en este punto, usted podría recibir cambios para README y trout.c. Esto le dice cierta información muy útilmdash;necesitará actualizar y coger los cambios del servidor para README antes de enviar sus cambios, o el repositorio rechazará su envío por estar fuera-de-fecha. (Más de este tema más adelante.)

svn diff

Otra manera de examinar sus cambios es con el comando svn diff. Puede descubrir exactamente cómo ha modificado cosas ejecutando svn diff sin argumentos, el cual imprime los cambios de los ficheros en formato unificado del diff:[10]

$ svn diff
Index: bar.c
===================================================================
--- bar.c	(revision 3)
+++ bar.c	(working copy)
@@ -1,7 +1,12 @@
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <unistd.h>
+
+#include <stdio.h>

 int main(void) {
-  printf("Sixty-four slices of American Cheese...\n");
+  printf("Sixty-five slices of American Cheese...\n");
 return 0;
 }

Index: README
===================================================================
--- README	(revision 3)
+++ README	(working copy)
@@ -193,3 +193,4 @@ 
+Note to self:  pick up laundry.

Index: stuff/fish.c
===================================================================
--- stuff/fish.c	(revision 1)
+++ stuff/fish.c	(working copy)
-Welcome to the file known as 'fish'.
-Information on fish will be here soon.

Index: stuff/things/bloo.h
===================================================================
--- stuff/things/bloo.h	(revision 8)
+++ stuff/things/bloo.h	(working copy)
+Here is a new file to describe
+things about bloo.

El comando svn diff produce esta salida comparando sus ficheros de copia de trabajo contra la copia prístina almacenada en el área .svn. Los ficheros programados para la adición se visualizan como texto-añadido, y los ficheros programados para la eliminación son visualizados como texto eliminado.

La salida es visualizada en formato unificado del diff. Esto es, las lineas quitadas son empezadas con un - y las lineas añadidas son empezadas con un +. svn diff también imprime el nombre del fichero e información útil para el programa patch, así que puede generar parches redireccionando la salida del diff a un fichero:

$ svn diff > patchfile

Usted puede, por ejemplo, mandar por email el fichero de parche a otro desarrollador para la revisión o testeo antes de enviarlo.

svn revert

Ahora suponga que usted ve la salida del diff anterior, y se da cuenta que sus cambios a README son un error; quizás accidentalmente tecleó ese texto en el fichero equivocado en su editor

Esta es una oportunidad perfecta para usar svn revert.

$ svn revert README
Reverted 'README'

Subversion invierte el fichero a un estado pre-modificado reescribiéndolo con la copia prístina almacenada en el área .svn. Pero también observar que svn revert puede deshacer cualquier operación programada—por ejemplo, usted puede decidir que no quiere añadir un nuevo fichero después de todo:

$ svn status foo
?      foo

$ svn add foo
A         foo

$ svn revert foo
Reverted 'foo'

$ svn status foo
?      foo
[Nota] Nota

svn revert ITEM tiene exactamente el mismo efecto que suprimiendo ITEM de su copia de trabajo local y después ejecutando svn update -r BASE ITEM. Sin embargo, si está revirtiendo un fichero, svn revert tiene una diferencia muy considerable—no tiene que comunicarse con el repositorio para reponer su fichero.

O quizás usted quito equivocadamente un fichero del control de versión:

$ svn status README 
       README

$ svn delete README 
D         README

$ svn revert README
Reverted 'README'

$ svn status README
       README

Resolver conflictos (fusionando los cambios de otros)

Ya hemos visto cómo svn status -u puede predecir conflictos. Suponga que ejecuta svn update y ocurren algunas cosas interesantes

$ svn update
U  INSTALL
G  README
C  bar.c
Updated to revision 46.

Los códigos U y G no son causa para la inquietud; esos ficheros absorbieron limpiamente los cambios del repositorio. Los ficheros marcados con una U no contienen cambios locales pero fueron actUalizados con cambios del repositorio. La G representa merGed, lo que significa que el fichero tenía para comenzar cambios locales, pero los cambios que venían del repositorio no se solaparon de ninguna manera.

Pero la C representa conflicto. Esto significa que los cambios del servidor se solapan con los suyos propios, y ahora tiene que elegir manualmente entre ellos.

Siempre que ocurra un conflicto, ocurren tres cosas para ayudarle a notar y resolver ese conflicto:

  • Subversion imprime una C durante la actualización, y recuerda que el fichero está en un estado de conflicto.

  • Subversion coloca marcas de conflicto—secuencias especiales de texto que delimitan los lados del conflicto—en el fichero para demostrar visualmente las áreas solapadas.

  • Para cada fichero en conflicto, Subversion coloca tres ficheros extra en su copia de trabajo local:

    filename.mine

    Este es su fichero como existió en su copia de trabajo antes de que usted actualizara su copia de trabajo—esto es, sin marcas de conflicto. Este fichero tiene su últimos cambios y nada más.

    filename.rOLDREV

    Este es el fichero que era la revisión BASE antes de que usted actualizará su copia de trabajo. Esto es, el fichero que usted descargó antes de que hiciera su última edición.

    filename.rNEWREV

    Este es el fichero que su cliente de Subversion recibió del servidor justo cuando usted actualizó su copia de trabajo. Este fichero corresponde con la revisión HEAD del repositorio.

    Aquí OLDREV es el número de revisión del fichero en su directorio .svn y NEWREV es el número de revisión del HEAD del repositorio.

Por ejemplo, Sally hace cambios al fichero sandwich.txt en el repositorio. Harry acaba de cambiar el fichero en su copia de trabajo y lo ha enviado. Sally actualiza su copia de trabajo antes de enviarlo y recibe un conflicto:

$ svn update
C  sandwich.txt
Updated to revision 2.
$ ls -1
sandwich.txt
sandwich.txt.mine
sandwich.txt.r1
sandwich.txt.r2

En este punto, Subversion no le permitirá enviar el fichero sandwich.txt hasta que los tres ficheros temporales sean borrados.

$ svn commit --message "Add a few more things"
svn: Commit failed (details follow):
svn: Aborting commit: '/home/sally/svn-work/sandwich.txt' remains in conflict

Si obtiene un conflicto, necesita hacer una de tres cosas:

  • Fusionar el texto en conflicto a mano (examinando y editando las marcas de conflicto dentro del fichero).

  • Copiar uno de los ficheros temporales sobre su fichero de trabajo.

  • Ejecutar svn revert <filename> para eliminar todos sus cambios locales.

Una vez que usted haya resuelto el conflicto, necesita dejar que Subversion lo sepa ejecutando svn resolved. Esto borrará los tres ficheros temporales y Subversion no considerará por más tiempo que el fichero está en estado de conflicto.[11]

$ svn resolved sandwich.txt
Resolved conflicted state of 'sandwich.txt'

Fusionando conflictos a mano

Fusionar conflictos a mano puede ser absolutamente intimidatorio la primera vez que lo haga, pero con un poco de practica, puede llegar a ser tan fácil como caerse de una bici.

Aquí tiene un ejemplo. Debido a una falta de comunicación, usted y Sally, su colaboradora, editan el fichero sandwich.txt en el mismo momento. Sally envía sus cambios, y cuando usted va a actualizar su copia de trabajo, obtiene un conflicto y vamos a tener que editar sandwich.txt para resolver los conflictos. Primero, echemos una hojeada al fichero:

$ cat sandwich.txt
Top piece of bread
Mayonnaise
Lettuce
Tomato
Provolone
<<<<<<< .mine
Salami
Mortadella
Prosciutto
=======
Sauerkraut
Grilled Chicken
>>>>>>> .r2
Creole Mustard
Bottom piece of bread

Las líneas de signos menor-que, y signos mayor-que son marcas de conflictos, y no son parte de los datos en conflicto actuales. Generalmente usted querrá asegurarse que estén borrados del fichero antes de su próximo envío. El texto entre las dos primeras marcas están compuestas por los cambios que usted hizo en el área conflictiva:

<<<<<<< .mine
Salami
Mortadella
Prosciutto
=======

El texto entre el segundo y tercer conjunto de marcas de conflicto es el texto del envío de Sally:

=======
Sauerkraut
Grilled Chicken
>>>>>>> .r2

Generalmente usted no deseará borrar las marcas de conflicto y los cambios de Sally—ella se sorprenderá terriblemente cuando llegue el sandwich y no sea lo que ella quería. Aquí es donde usted coge el teléfono o anda a través de la oficina y le explica a Sally que no puede tomar sauerkraut de un deli Italiano.[12]Una vez usted esté de acuerdo con los cambios deberá comprobarlos, editar su fichero y borrar las marcas de conflicto

Top piece of bread
Mayonnaise
Lettuce
Tomato
Provolone
Salami
Mortadella
Prosciutto
Creole Mustard
Bottom piece of bread

Ahora ejecute svn resolved, y está listo para enviar sus cambios:

$ svn resolved sandwich.txt
$ svn commit -m "Go ahead and use my sandwich, discarding Sally's edits."

Recuerde, si alguna vez está confuso mientras edita el fichero conflictivo, siempre puede consultar los tres ficheros que Subversion crea para usted en su copia de trabajo—incluyendo su fichero como estaba antes de que usted actualizara. Incluso puede usar una herramienta interactiva de fusión de una third-party para examinar esos tres fichero.

Copiando un fichero en su fichero de trabajo

Si obtiene un conflicto y decide que quiere rechazar sus cambios, simplemente usted puede copiar uno de los ficheros temporales creados por Subversion sobre el fichero en su copia de trabajo:

$ svn update
C  sandwich.txt
Updated to revision 2.
$ ls sandwich.*
sandwich.txt  sandwich.txt.mine  sandwich.txt.r2  sandwich.txt.r1
$ cp sandwich.txt.r2 sandwich.txt
$ svn resolved sandwich.txt

Punting: Usando svn revert

Si obtiene un conflicto, y al examinarlo decide que quiere rechazar sus cambios y empezar su edición de nuevo, simplemente invierta sus cambios:

$ svn revert sandwich.txt
Reverted 'sandwich.txt'
$ ls sandwich.*
sandwich.txt

Observe que cuando usted invierte un fichero conflictivo, no tiene que ejecutar svn resolved.

Ahora usted está listo para enviar sus cambios. Observe que svn resolved, al contrario de la mayoría de los otros comandos que nos hemos ocupado en este capitulo, requiere un argumento. En cualquier caso, debe tener cuidado y solo ejecutar svn resolved cuando esté seguro que ha arreglado el conflicto en su fichero—una vez los ficheros temporales son borrados, Subversion le dejará enviar el fichero incluso si todavía tiene marcas de conflicto.

Enviar sus cambios

¡Finalmente! Su edición está terminada, ha fusionado todos los cambios del servidor, y está listo para enviar sus cambios al repositorio.

El comando svn commit envía todos sus cambios al repositorio. Cuando usted envía un cambio, necesita proveer un mensaje de registro, describiendo su cambio. Su mensaje de registro será adjuntado a la nueva revisión que ha creado. Si su mensaje de registro es breve, puede querer proveerlo en la línea de comando usando la opción --message (o -m):

$ svn commit --message "Corrected number of cheese slices."
Sending        sandwich.txt
Transmitting file data .
Committed revision 3.

Sin embargo, si ha estado componiendo su mensaje de registro mientras trabaja, puede querer decirle a Subversion que coja el mensaje de un fichero pasando el nombre de fichero con la opción --file :

$ svn commit --file logmsg 
Sending        sandwich
Transmitting file data .
Committed revision 4.

Si usted falla en especificar cualquiera de las opciones --message o --file, entonces Subversion lanzará automáticamente su editor favorito (según lo definido en la variable de entorno $EDITOR) para redactar un mensaje de registro.

[Sugerencia] Sugerencia

Si está en su editor escribiendo un mensaje de registro y decide que quiere cancelar su envío, usted puede quitar su editor sin guardar los cambios. Si ya ha guardado su mensaje de registro, simplemente borre el texto y salve otra vez.

$ svn commit
Waiting for Emacs...Done

Log message unchanged or not specified
a)bort, c)ontinue, e)dit
a
$

El repositorio no sabe ni cuida si sus cambios tienen algún sentido en su totalidad; solo comprueba para asegurarse que nadie haya cambiado cualquiera de los mismos ficheros que usted mientras usted no miraba. Si alguien ha hecho esto, el envío entero fallará con un mensaje informándole que uno o más de sus ficheros está fuera-de-fecha:

$ svn commit --message "Add another rule"
Sending        rules.txt
svn: Commit failed (details follow):
svn: Out of date: 'rules.txt' in transaction 'g'

En este punto, necesita ejecutar svn update, ocupándose con cualquier fusión o conflicto que resulte y procure enviarlo otra vez.

Eso cubre el ciclo básico de trabajo para usar Subversion. Hay muchas otras características en Subversion que usted puede usar para administrar su repositorio y copia de trabajo, pero puede pasar fácilmente usando solo los comandos que hemos visto hasta ahora en este capítulo.



[6] N. del T.: La inicial usada representa la palabra Updated (actualizado) en el idioma inglés

[7] N. del T.: La inicial usada representa la palabra Deleted (borrado) en el idioma inglés

[8] N. del T.: merGed, fusionado, en inglés

[9] Por supuesto, nada es borrado totalmente del repositorio—solo delHEAD del repositorio. Puede conseguir cualquier cosa que borró descargando (o actualizando su copia de trabajo) a una revisión anterior a la que lo borró.

[10] Subversion usa su motor interno de diff, el cual produce un formato unificado del diff, por defecto. Si quiere la salida del diff en un formato diferente, especifique un programa diff externo usando --diff-cmd y pasando cualquier parámetro que quiera usando la opción --extensions. Por ejemplo, para ver diferencias locales en el fichero foo.c en contexto con el formato de salida mientras ignora cambios en espacios en blanco puede ejecutar svn diff --diff-cmd /usr/bin/diff --extensions '-bc' foo.c.

[11] Siempre puede borrar los ficheros temporales usted mismo, pero ¿realmente querría hacer eso cuando Subversion puede hacerlo para usted? No lo creemos.

[12] Y si les pregunta por esto, pueden echarle de la ciudad en un carril.