Contenido
- 1 Introducción
- 2 Instalando subversion
- 3 Haciendo el checkout
- 4 El subcomando help
- 5 Subiendo los cambios
- 6 Agregando archivos nuevos
- 7 Borrando archivos
- 8 El subcomando update
- 9 Viendo el historial de cambios
- 10 Viendo las diferencias entre versiones
- 11 Cambiando el lugar donde se hacen los cambios
- 12 Realizando un export
- 13 Etiquetando una versión
- 14 Excluyendo archivos
- 15 Referencias
Introducción
SVN es un sistema de control de versiones usado para que varios desarrolladores puedan trabajar en un mismo proyecto en forma más o menos ordenada. Tiene una arquitectura cliente servidor con controles de concurrencia para cuando varios desarrolladores estan trabajando en el mismo archivo y funciona más o menos así. En algún servidor se monta un repositorio SVN. En este lugar se van a registrar los cambios (revisiones) y los logs que se vayan generando. El cliente de SVN se baja una copia local de alguna revisión (generalmente la última), el desarrollador hace los cambios y los sube al servidor para que esten disponibles para los otros desarrolladores (además de generar un log con un comentario de que cosa modifico, para que, etc, etc, etc). La parte de configuración y puesta en marcha del servidor la dejo para otro documento y vamos a la parte importante, como usar el cliente de svn (desde la terminal). Para este documento usaré ~# como indicador de shell de root y ~$ como shell de usuario.Instalando subversion
Primero, hay que instalar un cliente de svn. En Lihuen eso se puede hacer instalando el paquete subversion desde Synaptic o simplemente corriendo desde una terminal con permisos de root los siguientes comandos:~#apt-get update ~#apt-get install subversionUna vez que tengamos instalados y configurados estos paquetes, creamos una carpeta en nuestro $HOME donde guardaremos nuestra copia local del repositorio.
~$ mkdir /$HOME/svnEn este ejemplo, si el usuario es pepito, mkdir creara un directorio en /home/pepito/ llamado svn. Ahora entramos al directorio que creamos recién.
~$ cd ~/svn
Haciendo el checkout
Para obtener una copia del trabajo tenemos que conocer la ubicación de un repositorio en internet. Uno bueno para probar es el mismo del proyecto SVN donde podremos obtener una copia del código fuente del mismísimo SVN. Eso se hace de la siguiente manera~/svn$ svn co http://svn.collab.net/repos/svnEl subcomando co tiene el mismo efecto que(de hecho, es un alias para) el subcomando checkout, asi que es lo mismo que poner
~/svn$ svn checkout http://svn.collab.net/repos/svnHay que tener en cuenta que esto puede tardar un buen rato, dependiendo de la velocidad de conección. Una ves terminado el proceso de descarga ya podemos empezar a modificar los archivos fuente. Generalmente, un repositorio estándar bien armado publica tres carpetas. Trunk, donde van los cambios principales y el hilo principal de desarrollo, branches, donde se introducen cambios importantes con respecto al desarrollo principal y tags, donde se congelan los cambios para una determinada versión. (Esto debería estar mejor explicado en el documento sobre configuraciones del servidor SVN) A medida que introducimos modificaciones, por ejemplo en la rama trunk, el estado de nuestra copia con respecto al repositorio original cambia. Podemos ver el estado de la copia de trabajo con el subcomando status
~/svn$ cd svn ~/svn/svn$ svn status A svn/trunk/subversion/tests/cmdline/svneditor.bat M svn/trunk/subversion/tests/cmdline/import_tests.py ! svn/trunk/subversion/tests/cmdline/svnadmin_tests.py ? svn/trunk/subversion/tests/cmdline/log_tests.py D svn/trunk/subversion/tests/cmdline/special_tests_data C svn/trunk/subversion/tests/cmdline/special_tests_data/bad-special-type.dumpY asi. Los códigos de la izquierda son los indicadores de estado, y se pueden ver con
~/svn$ svn help statusLos pasteo aquí como referencia los más relevantes.
' ' no hay modificaciones
'A' Agregado
'C' Presenta conflicto
'D' Eliminado
'I' Ignorado
'M' Modificado
'R' Reemplazado
'X' Este ítem no está versionado, pero es usado por una
definición de externals
'?' el ítem no está bajo control de versiones
'!' ítem faltante (removido por un comando ajeno a svn) o incompleto
'~' ítem versionado obstruido por algún otro ítem de un tipo diferente
'L' Copia bloqueada
La información de actualización aparece en la octava columna (con -u):
'*' hay una nueva revisión en el servidor
' ' la copia de trabajo está actualizada
Los campos restantes son de ancho variable y están delimitados por espacios:
La revisión de trabajo (con -u o -v)
La ultima revisión que se hizo commit y su autor(con -v)
La ruta de copia de trabajo siempre es el último campo, para que
pueda contener espacios en blanco.
El subcomando help
Lo anterior nos introduce al subcomando help. Con:~/svn$ svn help subcomandoPodremos ver la ayuda para el subcomando subcomando. Incluso en Lihuen, con bash_completion, si presionamos la tecla tab despues de poner svn help o svn , nos mostrará todos los posibles subcomandos.
Subiendo los cambios
Una ves que modificamos un archivo, si corremos el subcomando status nos debería mostrar la ruta al archivo precedido por la letra M indicando que fue modificado. Para compartir los cambios con los demás desarrolladores es necesario subir los cambios al repositorio. Esto se hace con el subcomando ci.~/svn/svn$ svn ciSVN necesita un comentario acerca de el o los archivos que se estan subiendo, por lo que abrirá el editor de texto por defecto. Una ves ingresado el comentario y guardados los cambios, iniciará el proceso de subida de archivos. Si el comentario no es muy largo y se quiere evitar el paso del editor, se puede introducir el comentario en la misma invocacion a ci.
~/svn/svn$ svn ci -m "Agregado el archivo foo.src; Modificado el archivo bar.src para proveer la funcionalidad pedida"Es posible que el repositorio no deje subir cambios salvo a usuarios registrados. Si este fuera el caso necesitará un usuario:contraseña para poder subir los cambios. El subcomando ci es en realidad un alias para commit, por lo ke poner uno u otro produce el mismo resultado.
Agregando archivos nuevos
Cuando se crean archivos o carpetas que no existian en la copia bajada del repositorio, en necesario agregarlas al control de versiones. Si corremos el subcomando status despues de haber creado archivos nuevos, aparecerán precedidos por un carácter ?, indicando que son archivos o carpetas desconocidas. Para agregar un archivo o una carpeta y todo su contenido al control de versiones se usa el subcomando add~/svn/svn$ svn add archivo.src carpeta/Cuando se agregan direcctorios al control de versiones, se ignorarán los archivos terminados en ~, ya que se asume que son backups. Los archivos seran agregados al repositorio en el siguiente commit.
Borrando archivos
De la misma forma que se pueden agregar archivos, se pueden borrar.~/svn/svn$ svn delete archivo.src carpeta/Este comando marcará para borrar el archivo archivo.src y la carpeta carpeta/ Si archivo.src o algún archivo dentro de carpeta/ fueron modificados, no se borrarán a menos que se indique el parámetro --force. Los archivos o carpetas seran borrados cuando se haga el commit. Son alias para delete, rm, del y remove.
El subcomando update
Cada vez que volvemos a trabajar sobre una copia de un repositorio pasado cierto tiempo, es necesario asegurarnos de que estamos trabajando sobre la última copia del repositorio. Para esto corremos el subcomando update~/svn/svn$ svn update En la revisión 106. ~/svn/svn$Si hay archivos nuevos, se mostrarán precedidos por una A. Hay otros códigos que marcan diferentes estados para archivos y carpetas. Los mas reelevantes son:
A Añadido D Borrado U Actualizado C Conflicto G CombinadoPara detalles pruebe svn help update Un archivo marcado como Combibado indica que dos o más desarrolladores lo modificaron en diferentes lugares. Un archivo marcado como Conflicto indica que dos o más desarrolladores lo modificaron en la misma línea. Más adelante veremos como resolver conflictos en archivos. Además el subcomando update nos permite copiarnos una revisión particular.
~/svn/svn$ svn update -r 104 En la revisión 104. ~/svn/svn$
Viendo el historial de cambios
Puede ser de utilidad saber que usuario modificó cierto archivo y que cambios realizó. Para esto se usa el subcomando log~/svn/svn$ svn logEsto mostrará todos los comentarios de cada uno de los commits hechos al repositorio. La salida de este comando puede ser muy larga, dependiendo del número de revisiones que tenga el repsoitorio. Para ver los logs de un número limitado de revisiones se puede usar el argumento -r
~/svn/svn$ svn log -r 31:35Mostrará solamente los logs de las revisiones 31 a 35. Para ver además las rutas de los archivos modificados se puede usar el argumento -v Aquí es donde se nota la importancia en la calidad de los comentarios. Cuanto más claro sea el comentario, menos líneas de mail o chat intercambiaremos con el resto de los desarrolladores preguntando por que es lo que hicieron en la última actualización.
Viendo las diferencias entre versiones
Para ver los cambios realizados a un archivo en particular entre la versión actual y la anterior pordemos usar el comando svn diff, algunas de las opciones son:$svn diff nombre_archivoEste comando indica las diferencias entre la versión del svn actualizado y la copia local nuestra.
$svn diff -r rev1:rev2 nombre_archivoDe esta forma podemos ver las diferencias entre dos versiones específicas, rev1 es la mas vieja y rev2 es la versión mas nueva contra la que queremos comparar.
Cambiando el lugar donde se hacen los cambios
A veces, la raíz del repositorio cambia de nombre, o de puerto. Sin embargo, cuando svn hace updates o commits, los hace contra el nombre antiguo. Es en estos casos cuando usamos el subcomando switch.~/svn/svn$ svn switch --relocate ruta_al_repo_antiguo nombre_del_repo_nuevo
Realizando un export
Si deseamos trabajar con los archivos fuera del ambiente svn, podemos exportar para evitar copiar los archivos ocultos svn mediante el subcomando export~/svn/svn$ svn export carpeta_origen carpeta_destinoLa carpeta destino no debe existir.
Etiquetando una versión
El etiquetado de versiones sirve para estabilizar los cambios de la rama trunk. Es como sacar una foto del proyecto y agregarle un nombre para que a partir de ese momento se lo conozca así. Así por ejemplo, la revisión 297 pasará a llamarse miprograma-version-0.5-1.Para taguear una versión basta con correr el siguiente comando
~/svn/svn$ svn copy http://nombre_del_repo/trunk -r #revisión http://nombre_del_repo/tags/nombre-de-la-etiqueta -m "comentario"Si se quiere etiquetar la ultima revisión se puede omitir el parámetro -r
Con el uso de SVN descubrimos que existe una mejor manera de taguear versiones, que consiste en hacer primero un export y luego un add.
Esto tiene dos principales ventajas. La primera es que el tag no entra al árbol svn inmediatamente (solo entra después de que se hace el add) y la segunda es que permite tener tags privados que no necesariamente tienen que agregarse al árbol después.
Excluyendo archivos
Si en el directorio que estamos trabajando se generan o agregamos manualmente tipos de archivos que no queremos subir al repositorio svn podemos generar una lista que los excluya. Nos posicionamos en el directorio de trabajo y ejecutamos en comando:svn propedit svn:ignore .Se abrirá un editor que permite listar por ejemplo:
*.aux *.logGuardamos y actualizamos, de esta forma de ahora en mas los archivos con las extensiones. aux y log, no se subirán al repositorio
Referencias
Libro de SubVersion en español (alcanza para empezar)http://svnbook.red-bean.com/nightly/es/index.html
Libro de SubVersion en inglés (más actulizado)
http://svnbook.red-bean.com/
