Novanebula blog

Emplear dos sistemas de control de versiones parece algo fuera de lugar a la hora de llevar un proyecto. Sin embargo muchas pueden ser las causas en las que emplear subversion y git puede ser muy provechoso. Por ejemplo en el caso de estos dos escenarios el empleo de ambos sistemas de versionado esta justificado:

- Repositorio central con subversion y posibilidad de trabajar offline con git en máquina local. Cuando el desarrollador vuelva a estar online puede comitear los cambios al repositorio central de subversion. Con tu copia de trabajo puedes trabajar offline puedes decir. Si pero no tienes ninguna de las capacidades de un control de versiones disponible.

- Repositorio central con subversion donde no se desea aumentar el número de ramas. Los desarrolladores pueden hacerse con el código en git y hacer ramas y otros repositorios clonados mientras dure el desarrollo de una característica específica luego se reúne el código y se comitea a subversión.

Veamos como puedes mezclar lo mejor de los dos mundos.

Continua leyendo "Empleando git y subversion"

Publicado por Abraham Covelo

En la tercera parte de este recetario sobre subversion hablaremos de tags y ramas. Haciendo incapié en su gestión y en como se emplean las ramas en situaciones reales de desarrollo de software.

Puedes encontrar la otras partes de este artículo a continuación:

Subversion y sus mejores recetas (1ª parte)

Subversion y sus mejores recetas (2ª parte)

Continua leyendo "Subversion y sus mejores recetas (3ª parte)"

Publicado por Abraham Covelo

¿Quien ha dicho que segundas partes nunca fueron buenas?

Continuando con la serie sobre subversión (subversión 1ª parte) seguimos con recetas rápidas para el uso de este sistema de control de versiones. En esta parte explicaremos algunas recetas para poder utilizar ramas de desarrollo paralelas.

Eliminar bloqueos (locks) que hayan quedado pendientes

$ svn cleanup
(a veces quedan locks sobre ficheros en tu copia de trabajo. Se retiran con este comando. Si alguna vez subversion se queja de un lock en tu copia de trabajo prueba este comando. Por ejemplo, a veces, svn status puede devolver una L (lock) sobre algún fichero, entonces hay que emplear este comando)

Concepto importante: Revisiones (revisions)

Una operación de commit (svn commit) publica cambios en cualquier cantidad de ficheros y/o directorios en una transacción atómica. Es decir las modificaciones que realices implicadas en un commit se realizan de manera indivisible, no existe posibilidad de que algún otro desarrollador vea o descargue en su copia de trabajo una modificación parcial de tu commit, lo ve todo o nada (si esta viendo o tiene una revisión no actualizada anterior a la tuya). Cada uno de estos commits crean una revisión que tiene asignado un número entero que comienza en cero (repositorio vacío) y que se va incrementando de 1 en 1 por cada commit exitoso. Cada revisión genera un nuevo "sistema de ficheros" que contiene el estado del repositorio después de los cambios efectuados por todos los commits anteriores a esta revisión incluyéndola.

Obtener la copia de trabajo de una fecha especifica en lugar de un número de revisión

$ svn checkout -r {"2006-02-17 15:30"}
(Obtiene como copia de trabajo la release más cercana anterior a la fecha 2006-02-17 15:30)


Crear una nueva rama de desarrollo (branching)

$ svn copy file:///var/svn/newrepos/myproject/trunk file:///var/svn/newrepos/myproject/branches/myfirstbranch -m "Creada una nueva rama llamada myfistbranch"
(Crea un nueva rama de desarrollo incluyendo un commit para que esta rama ya esté disponible en el repositorio)

Obtener una copia de trabajo de una rama de desarrollo

$ svn checkout file:///var/svn/newrepos/myproject/branches/myfirstbranch

Mantener tu rama de desarrollo en sincronía con la rama principal (trunk)

(Desde la copia de trabajo de tu rama de desarrollo, asegúrate de que tu copia de trabajo esta limpia svn status limpio)
$ svn commit -m "Llevar los cambios locales a la rama de desarrollo"
(Si creamos el branch en la revisión 9)
$ svn merge -r 9:HEAD ^/trunk
(mezclar los cambios procedentes de la rama principal (trunk) a tu copia de trabajo. Es posible que surjan conflictos que haya que resolver, el acento circunflejo es un alias de la url del repositorio)
$ svn commit -m "Actualizando rama con trunk"
(Se actualiza esta rama de desarrollo)


Mezclando los cambios de tu rama con la rama principal (trunk)

$ svn commit -m "Llevar los cambios locales a la rama de desarrollo"
$ svn merge -r 9:HEAD file:///var/svn/newrpos/myproject/trunk
(Volvemos a poner en sincronía la nueva rama)
$ svn commit -m "Actualizando rama con trunk"
$ svn merge --reintegrate ^/branches/myfirstbranch
(la rama es terminada aquí y no se debe trabajar con ella)
$ svn commit -m "Mezclar cambios en nueva rama a la rama principal"


Borrar rama

$ svn delete ^/branches/myfirstbranch -m "Eliminando rama myfirstbranch"
(Se borra pero el historial se puede revisar/reutilizar)

Llevar tu working copy a otra rama de desarrollo

$ svn switch ^/branches/myfirstbranch


Información sobre la copia de trabajo actual

$ svn info

Obtener información de mezclado de cambios que ya han sido llevados de la rama principal (trunk) a la nueva rama de desarrollo

(copia de trabajo es la nueva rama de desarrollo, /branches/myfirstbranch)
$ svn mergeinfo file:///var/svn/newrepos/myproject/trunk

Obtener cambios que aún deben ser mezclados desde la rama principal (trunk) a la nueva rama de desarrollo

(copia de trabajo es la nueva rama de desarrollo, /branches/myfirstbranch)
$ svn mergeinfo file:///var/svn/newrepos/myproject/trunk --show-revs eligible

Obtener informe de resultados de una mezcla sin hacerla realmente

(copia de trabajo es la nueva rama de desarrollo, /branches/myfirstbranch)
$ svn merge file:///var/svn/newrepos/myproject/trunk --dry-run

Echar atrás cambios ya realizados (comiteados)

(suponiendo que queremos echar atrás la revisión 101 que contiene graves errores)
$ svn merge -r 101:100 file:///var/svn/newrepos/myproject/trunk

ó

$ svn merge -c -101 file:///var/svn/newrepos/myproject/trunk
(actualizas tu copia de trabajo con lo que esta en la revisión 100)
$ svn diff
(compruebas los cambios)
$ svn commit -m "Deshaciendo los cambios de la revisión 101"


Recuperar un fichero borrado en una revisión anterior

(Tenemos un fichero llamado para_borrar.txt que se borró en la revisión 32 y queremos recuperarlo
$ svn copy http://svn.example.com/repos/calc/trunk/para_borrar.txt@31 ./para_borrar.txt
$ svn status
(Verificamos que se va a añadir)
$ svn commit -m "Recuperamos para_borrar.txt borrado en la revisión 32"

Así lo recuperaríamos con historial si por cualquier motivo no quisiéramos el historial de este archivo recuperado tenemos otra opción

Recuperar un fichero borrado en una revisión anterior eliminando su historial

$ svn cat http://svn.example.com/repos/calc/trunk/para_borrar.txt@31 > ./para_borrar.txt
$ svn add para_borrar.txt
$ svn commit -m "Re-creado el fichero para_borrar.txt de la revisión 31"

Recupera un fichero borrado en una revisión anterior sin tener una copia de trabajo

$ svn copy http://svn.example.com/repos/calc/trunk/para_borrar.txt@31 http://svn.example.com/repos/calc/trunk/para_borrar.txt -m "Recuperamos para_borrar.txt borrado en la revisión 32"

Espero que os haya sido de utilidad.

Publicado por Abraham Covelo

En este primer artículo haré un repaso a los comandos más comunes de subversion y a su utilización en un escenario real. Empezando desde la creación del repositorio hasta la generación de una nueva release para su salida a producción. En otros artículos extenderé la temática al empleo de ramas paralelas de desarrollo y la configuración de servidores locales y remotos de subversion. Empecemos por el principio

Crear un nuevo repositorio

$ sudo mkdir /var/svn
(creamos el directorio para albergar nuestros repositorios)
$ sudo chown $USER.$USER /var/svn
(asignamos este directorio al usuario actual para evitar problemas de permisos)

$ svnadmin create /var/svn/newrepos
(creamos un nuevo repositorio en /var/svn/newrepos
$ svn list file:///var/svn/newrepos
(listamos los ficheros incluidos en este repositorio, vacío de momento)

Importar ficheros al repositorio

$ mkdir -p tmp/branches tmp/tags tmp/trunk
(creamos los primeros directorios para introducir en el repositorio)
$ svn import tmp file:///var/svn/newrepos/myproject -m "Importación inicial"
(importamos el contenido del directorio tmp al repositorio dentro de la carpeta myproject con el commentario Importación inicial. myproject no es un directorio real dentro del sistemas de archivos es gestionado internamente por subversion)

Preparar nuestra copia de trabajo

$ mkdir myproject
(creamos el directorio donde situaremos nuestra copia de trabajo)
$ svn checkout file:///var/svn/newrepos/myproject/trunk .
(obtenemos los ficheros del directorio trunk del repositorio, en nuestro caso aún está vacío)

Añadir nuevos ficheros a nuestro proyecto

$ vi README
(creamos un nuevo fichero dentro de la copia de trabajo)
$ svn add REAME
(añadimos el fichero a los programados para ser añadidos al repositorio)
$ svn commit -m "Añadimos primer fichero README"
(enviamos los cambios al repositorio añadiendo el fichero README al mismo, el texto entrecomillado después del -m es un comentario sobre este envío)

Sincronizando con el repositorio

$ svn update
(Sincronizando con el contenido del repositorio por si hay cambios en los ficheros)

Copiar ficheros

$ svn copy README README2
$ svn commit -m "README copiado a README2"

Mover ficheros

$ svn move README2 README3
$ svn commit -m "Moviendo README2 a README3"

Borrar un fichero

$ svn del README3
$ svn commit -m "Borrando README3"

Creando un nuevo directorio

$ svn mkdir src
$ svn commit -m "Creando directorio src"

Comandos de apoyo

$ svn log
(registro de cada cambio hasta el último svn update ejecutado)
$ svn list
(Lista de ficheros hasta el último svn update ejecutado)
$ svn status
(Lista de tareas programadas para el siguiente commit basados en los cambios efectuados en la copia actual. Leyenda: A - fichero a añadir, D - fichero a borrar, C - conflictos con respecto al repositorio, M - Modificaciones locales, ? fichero no controlado por el sistema de versionado)

Modificar ficheros ya existentes y analizar cambios

$ vi README
(editamos README modificando su contenido)
$ svn diff
(vemos los cambios en ficheros)
$ svn commit -m "Modificaciones en README"


Deshacer modificaciones en tu copia de trabajo

$ vi README
(editamos README e introducimos algún error)
$ svn diff
(observamos de nuevo estos cambios en README)
$ svn revert README
(deshacemos las modificaciones sobre README, revert es capaz de deshacer cualquier modificación programada para el siguiente commit)

Tratamiento de conflictos

Anticipando posibles problemas antes de actualizar tu copia de trabajo

$ svn update -u

Actualizando con el repositorios (este retorna coflictos)

$ svn update
U INSTALL
G README
Conflict discovered in 'bar.c'.
Select: (p) postpone, (df) diff-full, (e) edit,
(h) help for more options:

Desde la versión 1.5 de subversion (interactive conflict resolution)

U (UPDATED) - fichero actualizado del repositorio (cambios sólo en el repositorio)
G (MERGED) - fichero actualizado del repositorio y con cambios locales combinados automáticamente
Conflict discovered in 'xxxx' - fichero actualizado en el repositorio y con cambios locales que se solapan. Hay que proceder a resolver el problema. Atención mientras no se resuelva el conflicto no se puede hacer commit de tus cambios al repositorio.

Las opciones son:

postpone - Deja en la copia local 3 archivos para ayudarte a resolver el conflicto. Suponiendo que el fichero en conflicto se llama filename estos son los 3 ficheros filename.mine (la versión en tu copia de trabajo), filename.r (la versión base de tu copia de trabajo, es decir, la del último update exitoso o en su defecto tu checkout), filename.r (la versión head del repositorio). Además filename incluye ahora el diff entre las dos versiones. La manera de resolver es:

Si quieres aceptar los cambios procedentes del repositorio y eliminar tus cambios

$ svn revert

ó

$ svn resolve --accept theirs-full filename

Si quieres subir tu versión y eliminar los cambios que hayan llegado con el update

$ svn resolve --accept mine-full filename

Recuerda que svn resolve eliminará las diferentes versiones del fichero conflictivo en tu copia de trabajo

Si se editan los cambios

$ vi filename
(se corrigen manualmente los conflictos)
$ svn resolve --accept working filename
(Se resuelve el conflicto)


$ svn commit -m "Conflicto resuelto en filename"
(Tras la resolución se envían los cambios al repositorio)


diff-full - Te devuelve las diferencias
edit - Edita directamente el archivo con las diferencias para resolver el conflicto desde este menu interactivo
resolved - Después de editarlo se declara el conflicto como resuelto
mine-full - Acepta tus cambios y elimina los procedentes del update
theis-full - Elimina tus cambios y acepta los procedentes del update
launch - Ejecuta un programa externo para resolver el conflicto (necesita preparación previa, introducir la variable de entorno SVN_MERGE o definir merge-tool-cmd en los ficheros de configuración de subversion. Al programa se le pasaran 4 ficheros (base, update, working y diff)
help - Muestra la lista de comandos disponibles

Enviando tus modificaciones

$ svn commit -m "Modificaciones"
(Envia los cambios de tu copia de trabajo al repositorio, si hay problemas y no se pueden enviar los cambios debes ejecutar un svn update para resolver conflictos tal y como comentaba previamente)

Ver el contenido de un fichero en una versión en particular

svn cat -r 3 README
(svn cat -r

Registro de cambios de una revision

$ svn log -r 4
(svn log -r )

Registro de cambios entre revisiones

$ svn log -r 3:5
(svn log -r :)

Comparando tu copia de trabajo con el repositorio

$ svn diff -r 3 README
(svn diff -r )

Comparando distintas versiones del repositorio

$ svn diff -r 3:4 README
(svn diff -r :

Devolviendo fichero del repositorio

$ svn cat -r 3 README
(svn cat -r

Crear una copia de trabajo de una versión antigua de tu repositorio

$ svn checkout -r 3
(svn checkout -r )
Atención, no se pueden enviar cambios desde esta copia de trabajo

Actualizar tu copia de trabajo a una versión antigua de tu repositorio

$ svn update -r 3 file:///var/svn/mirepo .
(svn update -r )
Atención, no se pueden enviar cambios desde esta copia de trabajo

Generar release

$ svn export file:///var/svn/newrepos/myproject/trunk

Geneare release de una versión en particular

$ svn export file:///var/svn/newrepos/myproject/trunk -r 3

Si os ha resultado útil esta artículo aquí tenéis otro con la 2ª parte sobre subversión.

Publicado por Abraham Covelo