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

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.aquinoDe 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 infoDe 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 CHANGELOGUna 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/tempEn 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 \ ..> --summarizePrimero, 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!