svn (IV): Ramas

He hablado en varias ocasiones en el blog sobre subversion, un sistema de control de versiones que he utilizado para llevar el control del código fuente de algunos programas. Una entrada que tenía pendiente desde casi hace un año es el uso de ramas (branches)

Ramas

Las ramas es una herramienta que nos permite seguir vías alternativas de desarrollo para poder posteriormente, si se desea, juntar los cambios en un camino principal. Supongamos que tenemos una serie de ficheros en los que estamos desarrollando que se llama trunk. Llegado el momento, queremos probar una serie de mejoras, una nueva funcionalidad, y no queremos que este código principal de desarrollo se toque, entonces lo que se crea es una nueva_rama, que no deja de ser una copia del código en un momento determinado del tiempo, donde el desarrollo diverge:

Cuando estamos en la situación del gráfico anterior hemos realizando una operación de crear una nueva rama en el punto uno. Podremos desarrollar en cualquiera de las ramas, (trunk o nueva_rama), y llegado el momento, lo normal es que integremos los cambios que nos interesen dentro de la rama trunk. ¿Por qué esta rama?. Porque por convenio, en subversion, la rama principal de desarrollo se llama así.

Normalmente la estructura de directorios un proyecto de subversion es tal como sigue:

proyecto
    trunk
    branches
    tags

Nosotros trabajamos dentro del directorio trunk que se corresponde con la rama principal de desarrollo. Ahora, ¿Cómo se crea una nueva rama a partir de una rama existente o la principal?. Pues se usa una copia de la rama que deseemos, usando el comando svn copy. Así por ejemplo, para copiar desde la rama trunk a nueva_rama tal como se ve en el caso anterior. En este caso estamos dentro de un repositorio de un proyecto llamado proyecto_svn

swordcoast:proyecto_svn terron$ svn copy trunk branches/nueva_rama
A         branches/nueva_rama
swordcoast:proyecto_svn terron$ svn status
A  +    branches/nueva_rama
swordcoast:proyecto_svn terron$ svn commit
swordcoast:proyecto_svn terron$cd branches/nueva_rama

Tras ejecutar la última orden, estaremos dentro del directorio de nueva rama, podremos seguir editando y modificando la misma, sin tocar la rama trunk, o bien mientras otros desarrolladores tocan dicha rama. Un detalle interesante respecto al concepto de rama dentro de subversion, es que realmente no hay ninguna "rama" real ni ninguna estructura interna que haga referencia a la misma, sino que no deja de ser una copia de un directorio determinado.

La última operación que nos queda cuando usamos ramas es mezclar (merge) los cambios de dos ramas. ¿Cómo realizamos dicha operacion?.A través del comando svn merge. Lo primero que debemos saber es la revisión que tiene cada rama que deseemos mezclar. Si seguimos con nuestro ejemplo, supongamos que la rama trunk está en la revisión 100 y la rama nueva_rama está en la revisión 150. Queremos incorporar a la rama trunk todos los cambios que hemos realizado en la rama nueva_rama. Para ello, dentro de nuestro directorio de proyecto:

cd trunk
svn merge -r 150:100 ../branches/nueva_rama
svn commit

Si todo va bien, la secuencias de comandos anteriores incorporará a la rama trunk los cambio que hemos desarrollado en la rama nueva_rama. A partir de aquí podemos dar por finalizado el trabajo en dicha rama, o bien seguir trabajando en las dos - esto es útil cuando se quiere tener una rama de desarrollo y otra estable, por poner un ejemplo sencillo -.

Sin embargo, puede producirse conflictos entre las versiones que la lógica automática del subversion sea incapaz de corregir. Llegado el momento, el sistema nos preguntará que queremos hacer:

Select: (p) postpone, (df) diff-full, (e) edit, (r) resolved,
        (mc) mine-conflict, (tc) theirs-conflict,
        (s) show all options:

Lo que nos está pidiendo el sistema es una serie de opciones para ver que hacemos con aquellos merge que hayan fallado:

• p Dejar los cambios para más tarde.
• df Nos muestra un diff completo de todos los ficheros que han cambiado.
• e Editamos el fichero que ha fallado al hacer el merge, para editarlo manualmente.
• r Damos el merge por resuelto.

Lo normal en caso de que haya ocurrido un error en esta fase, es editarlo, resolviendo los posibles conflictos y luego hacer el commit. El tema de conflictos entre ficheros, lo trataré en un artículo posterior, de momento dejo aquí estas pequeñas pinceladas de como resolverlo.

Referencia

1. Control de versiones con subversion
2. Uso de Branches y Tags con SVN
3. Copying Changes Between Branches

---

Technorati Tags: svn

Usar svn sobre ssh

Hace tiempo que vengo buscando de como usar Subversion para el control de código fuente de un proyecto a través de ssh, sin necesidad de instalar WebDAV. Es mucho más sencillo y puedo disponer de la arquitectura de clave pública / privada, sin necesidad de montar un servidor web y sobre él el Apache para dar soporte WebDAV o bien el servidor svnserve a través del inetd.

Para poder usar el ssh, aparte de estar corriendo en el servidor, necesitamos tener la ruta del repositorio y permisos para poder acceder al mismo con el usuario que usemos para acceder a la máquina. En este caso, no estoy usando un repositorio compartido, sino uno propio en una máquina a la que tengo acceso, por lo cual no tengo necesidad de usar un repositorio compartido.

Para acceder al repositorio lo que hay que hacer es usar la url de acceo svn+ssh para acceder al repositorio remoto. Así, por ejemplo si el PATH absuluto de un repositorio es /var/lib/svn en la máquina myhost, y el módulo que deseemos hacer un checkout del módulo llamado programa, lo que se debe de hacer es la siguiente secuencia de órdenes:

svn co svn+ssh://myhosts/var/lib/svn programa

Si la autentificación se ha montado en el ssh usando contraseñas, el ssh nos pedirá la contraseña, y se bajará una copia de trabajo del repositorio programa, que grabará en un directorio con el mismo nombre.

Decir que una vez que tengamos una copia de trabajo, no es necesario añadir la URL completa para realizar las diferentes operaciones con subversion. Eso sí, a menos que se cree un diseño de autentificación con claves públicas y privadas, cada vez que realicemos una operación con el ssh, nos pedirá la contraseña de acceso.

En caso de que se necesite opciones especiales para pasar al ssh, por ejemplo, para indicar el puerto en el que está escuchando el servidor ssh al cual nos queremos conectar, se puede usar la variable de entorno SVN_SSH para indicar las diferentes opciones que se deseen usar. Por ejemplo, supongamos que el servidor ssh al cual desee conectarse está en el puerto 10000 y que el usuario que utilice sea user_svn, establecemos la variable de entorno de la siguiente manera:

export SVN_SSH='ssh -l user_svn -oPort=10000'

---

Technorati Tags: svn

Breves notas de svn (III): Manejando los recursos bajo el control de versiones

Cuando se trabaja bajo un sistema de control de versiones, en caso de modificar la estructura de los ficheros que se encuentran bajo su control, hay que notificar al sistema que se ha realizado cambios (añadir o borrar directorios, añadir o borrar ficheros, cambiar ficheros o directorios de su actual ubicación. Si consideramos el svn como un sistema de ficheros virtual con un control de versiones, existirán los correspondientes comandos para crear directorios, borrar directorios y archivos, añadir archivos mover archivos en el árbol de directorios y copiar archivos. Con los siguientes comandos, se pueden realizar las operaciones necesarias:

Añadir ficheros

Cuando deseamos añadir un nuevo fichero al control de versiones, hay que usar la orden svn add fichero. Desde este momento, en nuestra copia de trabajo, el fichero está bajo el control de svn. Los cambios deben de enviarse al repositorio con la correspondiente orden svn commit

Borrar ficheros y directorios

Si queremos borrar un fichero del repositorio, se usa la orden svn del fichero. Esta orden nos va a borrar tanto la copia local que estemos usando como la copia en el repositorio una vez que se ejecuta el svn commit. Una comprobación que realiza svn en caso de borrar un directorio es asegurarse que todos los ficheros que contienen están bajo el control de versiones. En caso de que no sea así, no ejecutará la operación de borrado pedida, a menos que se le pase el parámetro --force

Añadir directorios

Si se desea añadir un directorio bajo el control de svn, se usa la orden svn mkdir directorio. Nos va a crear el directorio en nuestra estructura de directorios local, y los cambios se subirán al repositorio una vez que se ejecute la orden svn commmit

Renombrar o mover archivos y directorios

Para mover objetos dentro de la estructura que está bajo el control de versiones,se usa la orden svn mv fichero1 [fichero2, fichero3,...] destino

Copiar ficheros

Si queremos copiar ficheros dentro del árbol de directorios bajo el control de versiones se usará la orden svn cp origen destino.

Referencias

1. Version Control with Subversion
2. Subversion (SVN)

Technorati Tags: svn

Breves notas sobre svn (II): Como evitar que ficheros y directorios no estén bajo el control de versiones

Sigo trabajando con subversion como sistema de gestión de código fuente (aunque he tomado buena nota de los comentarios que me dejaron en la primera entrada, probaré otros sistemas de gestión cuando tenga un hueco).

Ahora me he encontrado el problema, tras haber importado un árbol completo de directorios, que necesito que ciertos ficheros y ciertos directorios no estén bajo el control de versiones. ¿Cómo se puede realizar esta exclusión?. Pues hay que seguir varios pasos:

1. Si los ficheros están bajo el control de versiones, eliminar del repositorio los mismos.
   Por ejemplo, si estamos en la raíz de nuestro proyecto, y quisiéramos eliminar el directorio build:

   svn delete build
   svn commit

   O por ejemplo, si queremos que no estén bajo el control de versiones todos los ficheros intermedios del proceso de compilación, que son de la forma moc_*.cpp:

   svn delete moc_*.cpp
   svn commit

2. Añadir una propiedad a los directorios donde queremos que se ignores los ficheros. Esta propiedad es svn:ignore. Así por ejemplo, para ignorar en el directorio raíz todos los ficheros cuyo nombre coincidan con el patrón moc_*.cpp:

   svn propset svn:ignore moc_\*.cpp .
   svn commit

   Ojo en este caso: la contrabarra, \, se utiliza para escapar el asterisco del shell y el . es necesario para indicar que se va a modificar las propiedades del directorio actual, que es donde queremos ignorar
3. Como puede verse, la propiedad se almacena en el servidor, por lo cual es imprescindible hacer un commit de los cambios para que estos queden reflejados en el repositorio.

¿Qué pasaría si quisiéramos ignorar varios archivos o varios subdirectorios?. En este caso, cada uno de los patrones de archivos o subdirectorios debe de estar separado por un carácter de nueva línea. Hay varias maneras de conseguir este efecto:

1. Usar un fichero y la opción -F del svn. Supongamos que queremos ignorar todos los ficheros contenidos en los directorios build y Debug. Para ello creamos un fichero que por simplicidad vamos a llamar ignore.txt, donde cada línea corresponde a cada uno de los directorios que queremos ignorar:

   svn propset svn:ignore -F ignore.txt .
   svn commit

2. Otra opción es usar las comillas e ir introduciendo cada patrón de ficheros en una nueva línea. Para ignorar los mismos directorios que en el caso anterior:

   svn propset svn:ignore 'build[ENTER]
   Debug[ENTER]
   ' .
   svn commit

Para obtener el listado de ficheros que está ignorando actualmete svn se consulta el estado y se pasa la opción --no-ignore:

svn status --no-ignore

También existe la posibilidad de hacer que subversion ignore los ficheros a nivel global. Para ello debe de editarse el fichero de configuración, config, y modificar en la sección miscellany, el parámetro global-ignores. Por defecto subversion ignora los ficheros con las cuyos nombres coincidan con los patrones*.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store

Referencias

1. How to … Make Subversion ignore files and folders
2. Version Control with Subversion
3. Subversion (SVN)

Technorati Tags: svn

Breves notas sobre svn (I)

Llevo algún tiempo buscando montar un pequeño sistema de control de versiones que me sirva para poder controlar los cambios que hago a algunos scripts y algún código que escribo. He decido pasar del clásico cvs y probar subversion. Subversión lo que nos ofrece es un sistema de ficheros virtuales, donde existe una versión de cada fichero y cada directorio modificado. De esto podemos recuperar una versión concreta de cualquier elemento.

En el caso de svn todo gira entorno a un repositorio. A este se puede acceder a través de diferentes métodos: sistema de ficheros locales, webdav (http y https) y el protocolo propio de svn, el cual puede,en un momento dado encapsularse sobre ssh.

Una cosa importante es como svn versiona los ficheros y directorios que están bajo su control con un número de revisión que afecta a todo el árbol que está bajo su control.

Pequeña chuleta de comandos svn

• Crear un repositorio de subversion
  svnadmin create /path/repositorio
• Importar un árbol de directorios dentro de un repositorio
  svn import /dir/proyecto file://path/repositorio/proyecto -m "Comentario"
• Hacer un checkout de un proyecto
  svn checkout file:///path/repositorio/ proyecto
• Obtener diferencia entre versiones
  svn diff
• Diferencia entre la versiones
  
• Añade los cambios realizados en nuestros ficheros locales al repositorio.
  svn commit
• Actualiza nuestra copia local de ficheros con la última versión disponible en el repositorio.
  svn update
• Muestra un histórico de los cambios del proyecto
  svn log
• Borrar un fichero o un directorio del repositorio

svn delete directory
• Acceso a repositorios
• file:///, al repositorio se accede a través de ficheros locales.
• http://, al repositorios se accede a través de webdav sobre http.
• https://, al repositorio se accede a través de webdav sobre https.
• svn://, al repositorio se accede a través del servicio implementado en svnserver.
• svn+ssh://, al repositorio se accede a través del servicio implementado sobre svnserver pero tunelizado a través de ssh.

Referecias

• Control de versiones con Subversion.

Technorati Tags: svn