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:

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.)

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.

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

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

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

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

$ 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

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

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.

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

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.