nibbles: unas notas de subversion (Wata~negui~consup)


Subversion

"Apache Subversion (often abbreviated SVN, after the command name svn) is a software versioning and a revision control system founded and sponsored in 2000 by CollabNet Inc. Developers use Subversion to maintain current and historical versions of files such as source code, web pages, and documentation. Its goal is to be a mostly-compatible successor to the widely used Concurrent Versions System (CVS)."
-- from Wikipedia [search: apache subversion]



De una lista que terminó en receta...

Ok, la idea original era hacer una receta de cocina usando un flujo de cambios en subversion, pero pues como poco a poco le estoy agarrando el modo a esto de la blogeada, terminó finalmente en una lista de  comandos que nos han resultado utiles en el equipo de trabajo.

Si llegaron a usar CVS, recordarán que Apache Subversion fue una fuerte apuesta como sistema de control de versiones diseñado específicamente para reemplazar CVS esto dentro de las alternativas Open Source / Free Software, su diseño es centralizado y como dato de referencia: es la herramienta a usar cuando subes tu código a Google Code. Una característica importante de Subversion es que, a diferencia de CVS  los archivos en control no tienen cada uno un número de revisión independiente (como es el caso en GiT), es decir; todo el repositorio tiene un único número de versión que identifica un estado general de los archivos del repositorio en un momento determinado.

Para quienes gustan de trabajar sin estar conectados encontrarán un pequeño detalle,  su diseño es centralizado y no distribuido, por lo tanto para registrar los cambios será necesario estar conectado al repositorio central o crear un repositorio local.

La receta pues...

Así que veamos, los ingredientes necesarios son:
  • Una cucharada de Apache Subversion
  • Una cantidad generosa de archivos y directorios (si, un proyecto personal puede servir)
  • Un repositorio donde colocar los archivos sazonados
  • Un par de huevos
Para efectos de esta receta usaremos un repositorio de Google Code, por lo que si tienen una cuenta de GMail deben saber que también cuentan con espacio para subir código.


Las pantallas de registro son bastante sencillas, datos como el nombre del proyecto y un resumen de su funcionalidad, así como el tipo de licencia son necesarios, por cierto que al momento que estoy escribiendo esto leo con agrado que ya es posible usar GiT como sistema de control de versiones, aunándose a las ya existentes opciones: Apache Subversion y Mercurial.

Otros aspectos interesantes de esta herramienta es que nos provee de un visor completo para código, un sistema para administración de incidentes de software (bug tracking) y una wiki para documentar el proyecto (por cierto, un etiquetado tipo markdown no les caería mal), la página principal  nos da un panorama del estado actual del proyecto y en general, se percibe como una herramienta madura (aunque ciertamente le faltan muchos aspectos que GitHub o Gitorious si cubren).

Veamos entonces...

[0001] Creando una copia de trabajo

Necesitamos crear una copia de trabajo, por lo tanto lo primero que haremos será hacer una copia remota de la rama de trabajo principal (trunk).
andresaquino $ svn help checkout
checkout (co): Check out a working copy from a repository.
usage: checkout URL[@REV]... [PATH]

andresaquino $ svn \
 ..> checkout \
 ..> https://shtemplate.googlecode.com/svn/trunk \
 ..> shtemplate.svn \
 ..> --username andres.aquino

De esta manera, generamos una copia de trabajo de la rama principal del proyecto lo cual, nos permitira hacer las actualizaciones/cambios que hagamos durante el desarrollo del proyecto.

[0010] Verificando información del Repositorio

Es muy común perder las nociones de donde esta ubicado el repositorio y los últimos cambios realizados, para ello usaremos info para obtener información del proyecto.
andresaquino $ svn help info
info: Display information about a local or remote item.
usage: info [TARGET[@REV]...]

andresaquino $ svn info

De esta manera puedo ver que me encuentro en la rama principal de trabajo y que el último cambio esta documentando en la revisión 2.

[0011] Guardando los cambios en el repositorio

Ya dentro del proyecto puedo observar que hay ciertos detalles con el archivo README, por lo tanto me gustaría hacer ciertas correcciones, para ello haremos los cambios en el archivo antes mencionado y y posterior a ello, registraremos los cambios bajo un número de revisión que subversion nos asigne. Para realizar este paso nos podremos auxiliar de dos opciones: status y update.
andresaquino $ svn help commit
commit (ci): Send changes from your working copy to the repository.
usage: commit [PATH...]

andresaquino $ svn help status
status (stat, st): Print the status of working copy files and directories.
usage: status [PATH...]

andresaquino $ svn help update
update (up): Bring changes from the repository into the working copy.
usage: update [PATH...]

andresaquino $ svn \
 ..> commit \
 ..> -m "TASK: misspelled issues README"

Como puede observarse en la pantalla, es necesario ejecutar un status antes de registrar los cambios para verificar que otros archivos van a empujarse en el commit o lista de actualizaciones de la revisión (5), y posterior a ello será conveniente ejecuten un update a su repositorio para que puedan consultar el registro (log) del sistema y ver los cambios reflejados.

[0100] Crear una nueva rama de trabajo (branch)

Como pueden observar hasta este punto estamos trabajando con la rama principal del proyecto, lo cual puede no ser muy conveniente ya que si estamos trabajando en grupo muy seguramente afectaremos los cambios de los demás, luego entonces sería conveniente tener una rama de trabajo independiente donde podamos realizar nuestros cambios y ya validados, integrarlos a la rama principal. Para realizar esto será necesario crear una nueva rama de trabajo (branch), es importante denotar que no existe como tal un proceso formal para generar una nueva rama de trabajo; así que lo que haremos será copiar el trunk sobre el directorio de branch y hacer un checkout de esa copia para trabajar en ella.
andresaquino $ svn help copy
copy (cp): Duplicate something in working copy or repository, remembering
history.
usage: copy SRC[@REV]... DST

andresaquino $ svn \
 ..> copy \
 ..> https://shtemplate.googlecode.com/svn/trunk \
 ..> https://shtemplate.googlecode.com/svn/branches/using-libs \
 ..> -m "TASK: creating new branch - Using some libraries"

Observen que incluso las copias llevaran un registro de cambio, lo cual no se me hace tan buena idea sin embargo tampoco nos afecta, verdad?

hecho esto será necesario bajar esa rama para poder trabajar y aplicar nuestros cambios, entonces lo que haremos será listar (list) los branch existentes, una vez que identificamos el branch que requerimos nos hacemos de el ejecutando un checkout.

[0101] Agregar nuevos componentes a un repositorio

Vamos a agregar un archivo de registro de cambios, en caso de que bajen el proyecto como un tar.gz se tenga un archivo donde se documenten los cambios realizados al proyecto.
andresaquino $ svn help add
add: Put files and directories under version control, scheduling
them for addition to repository.  They will be added in next commit.
usage: add PATH...

andresaquino $ svn add CHANGELOG 
A         CHANGELOG
                  
Una vez realizado esto, registramos los cambios en un commit y actualizamos nuestro repositorio (commit; update)

[0110] Eliminando componentes de un repositorio

Suele suceder que por error sube uno archivos o directorios que no son relevantes para el repositorio, como puede ser archivos de log o contraseñas, por lo tanto como parte del mantenimiento de nuestros repositorios será necesario eliminar esos componentes no deseados.
andresaquino $ svn help del
delete (del, remove, rm): Remove files and directories from version control.
usage: 1. delete PATH...
       2. delete URL...

andresaquino $ svn del logs/*
D         logs/MARConciliacion.log
D         logs/temp
                  
En este caso borramos archivos de log y registramos el cambio.

[0111] Actualizando la información al repositorio principal

Bueno hasta este momento hemos realizado cambios en un branch, ahora bien tenemos que integrar los cambios que hasta este momento se hayan sucedido en el flujo principal (trunk) y posteriormente, hacer la integración del proyecto (merge).
andresaquino $ svn help diff
diff (di): Display the differences between two revisions or paths.
usage: 1. diff [-c M | -r N[:M]] [TARGET[@REV]...]
       2. diff [-r N[:M]] --old=OLD-TGT[@OLDREV] [--new=NEW-TGT[@NEWREV]] \
               [PATH...]
       3. diff OLD-URL[@OLDREV] NEW-URL[@NEWREV]

andresaquino $ svn \
 ..> diff \
 ..> --old https://shtemplate.googlecode.com/svn/trunk \
 ..> --new https://shtemplate.googlecode.com/svn/branches/using-libs \
 ..> --summarize

Primero, vamos a validar si tenemos cambios entre nuestro branch y el trunk, de esta manera antes de actualizar el trunk principal necesitamos tener nuestro branch actualizado para no romper las cosas (diff)

En este caso, vemos que desde el trunk a nuestro branch se borraron dos archivos y se agrego uno; ya que validamos esto entonces vamos a importar los cambios en el trunk (merge & status)

Actualizamos el repositorio principal (commit & update) y verificamos el log de nuestro repositorio para verificar que el cambio fue registrado (log).

Si nos vamos a la página del proyecto en Google Code podremos validar que estos cambios se realizaron de manera correcta, observen que el registro de la revisión 9 habla de la integración

Si nos movemos a esa liga, obtendremos más información del cambio realizado.

Bastante sencillo, bueno pues tiempo de practicar!
¿Se animan?

Para el buzón..

Si se preguntan por el "Wata~negui~consup"es por aquella canción que decía "What a very good soup!" (Sopa de Caracol), pero como era guapachosa y pegajosa, pocos nos dimos idea de que diablos decía! Total que para hacer este post me anime con semejante rola, pero para estos momentos ya me dió indigestión..
La cosa era moverse al ritmo de tan singular canción; ahora saben una cosa más, no era una aberración sopeada, era: "What a very good soup!"

Referencias



buen camino!

Popular Posts