Mostrando entradas con la etiqueta subversion. Mostrar todas las entradas
Mostrando entradas con la etiqueta subversion. Mostrar todas las entradas

lunes, septiembre 05, 2011

El Cliente Ideal de Control de Versiones

"Subversion Wallpaper, por Michael Pilato"

Desde que conocí el control de versiones este se ha vuelto una parte crucial de mis actividades de desarrollo de aplicaciones permitiéndome resguardar el código en un servidor pudiendo recobrar y comparar contra los cambios efectuados en el pasado así como llevar un control de las ramificaciones de mis aplicaicones y si aun no lo utilizan se los recomiendo enfáticamente y muy especialmente si (como es muy común) trabajan dentro de un equipo de desarrollo que en conjunto realizan cambios simultáneos a los mismos archivos de código fuente.

En su debido momento escribí un par de posts(parte 1 y parte 2) acerca del control de versiones en el cual explico de una manera un poco más detallada en que consiste el control e versiones, cuánto me ha servido en mi carrera y porqué considero que deberían utilizarlo. SVN es mi solución preferida de control de veriones. Es, en mi punto de vista, la evolución natural de CVS y se mantiene un tanto conservador comparado contra Git, Bazaar y Mercurial además de ser quizás el que tenga la mayor cantidad de clientes y documentación disponible. Me complica un tanto la vida al momento de incorporar cambios de una rama a otra pero hasta el momento he sobrevivido a ello.

Con todas las bondades conocidas y publicadas acerca de SVN y su variedad de sabores de clientes, tanto de línea de comandos, de escritorio o integrados en el IDE he llegado a un punto en el que durante mis experiencias como programador  mis necesidades superaron a las características ofrecidas por estos clientes y necesito algo más para administrarlo. A continuación mis escenarios en los cuales no he podido encontrar un cliente de SVN que supla mis necesidades:

  • Fases posteriores al desarrollo. Resulta que en algunos flujos de desarrollo en los que he participado se realizan diferentes fases en las cuales el código fuente pasa por diferentes personas, desde mi persona como desarrollador hasta analistas de calidad y quienes despliegan en producción la versión final. En otras ocasiones he tenido que pasar mi código fuente por otros desarrolladores quienes realizan pruebas cruzadas de mi código. Aunque he encontrado SVN te permite explorar, graficar y generar reportes de las diferentes revisiones, no he encontrado alguna herramienta que me permita catalogar mi código en base a las fases por las que este atraviesa y en manos de quien se encuentra el código fuente lo cual permitiría una mejor administración del mismo cuando se desean, por ejemplo, obtener métricas de cantidad de cambios y tiempo/esfuerzo invertido durante una fase determinada.
  • Choque de versiones concurrentes. Me ha ocurrido ya demasiadas veces que me solicitan desarrollar una nueva funcionalidad para un componente pero me entero que alguien más también tiene en fase de desarrollo o pruebas otra versión de este mismo componente las cuales, como pasarán a producción antes que mi versión, yo debo procurar incorporarlas para que cuando yo pase mi versión a producción esta sea una combinación de ambas. Mediante la creación de una rama por cada versión concurrente he logrado solucionar el problema a nivel de control de cambios e incorporación de revisiones de una rama a otra y esta solución ha sobrevivido aún a escenarios más bizarros como cuando ambos componentes deben pasar a producción en una misma fecha o cuando estos cambian de prioridad para pasar a producción mientras ambos se encuentran en fase de pruebas de calidad. Aun así, hasta el momento no he encontrado un cliente de SVN que me permita ver de una manera gráfica y detallada (número de revisión, autor, mensaje añadido a la revisión, fecha y fase) de las ramificaciones hechas a la rama principal de la línea de tiempo de un componente, lo cual me parece muy importante para llevar un control de desarrollos concurrentes, manejo de prioridades y reportería para jefes inmediatos. Un gráfico y estadísticas similares a las de Ohloh pero visualmente más detallados y mayormente enfocados en la línea de tiempo, las fases y las ramificaciones.
"Línea de tiempo en Ohloh. Si tan solo mostrara más detalles y las ramificaciones"
  • Administración de usuarios y accesos a las ramas. Me encantaría contar con un cliente o herramienta de SVN un poco más orientado para un usuario administrador de repositorios, el cual, además de permitirte explorar el código fuente, los detalles de las revisiones y comparaciones entre una revisión y otra también te permitiera configurar usuarios y roles de acceso a una línea de tiempo y sus diferentes ramificaciones. Me encantaría especialmente poder configurar un repositorio para que los usuarios y sus permisos residieran en un servidor LDAP y no depender de un archivo de configuración de apache o nativo de SVN.
  • Notificaciones. Algunas herramientas  que he conocido me permiten generar un RSS feed de cada uno de los commits realizados sobre un repositorio pero alguien como un project manager o un team manager quizás no esté interesado en todo el detalle de un commit y le sea de mayor interés commits específicos como la creación de una nueva rama para un desarrollo concurrente, el cambio de fase de desarrollo a testing (y su correspondiente detalle como número de revisión, autor, fecha y descripción) o el merge de una rama a la línea de tiempo principal (que equivaldría a un evento como un paso a producción) lo cual complementaría mi necesidad mencionada en primer punto: el manejo o clasificación de revisiones por medio de fases. Como un plus me interesaría que además de notificar también requiera la autorización de un superior para la realización de un commit a una determinada fase, como por ejemplo, un cambio hacia la fase de testing o hacia la fase de producción.
Hasta el momento sigo buscando un cliente (o grupo de clientes, al menos) o herramienta que pudiera suplirme estas cuatro necesidades básicas que he llegado a requerir para trabajar con control de versiones con mis equipos de desarrollo pero debido al tiempo que llevo buscando y los pocos y desfavorables resultados obtenidos en mi búsqueda he llegado a considerar la alternativa de desarrollar mi propio cliente de SVN basado en algún cliente existente cuya licencia me permita expandir su funcionalidad y su código fuente pertenezca a un lenguaje que yo conozca. En caso de no encontrar un cliente existente me veré obligado a desarrollarlo desde cero lo cual considero que me llevará mas tiempo pero tendré una mejor oportunidad para adaptarlo a mis necesidades. En un post posterior relataré mi experiencia tratando de desarrollar mi cliente de SVN.

Dejo además abierta la invitación a mis queridos lectores para sugerirme clientes de SVN que ustedes conozcan y consideren capaces de suplirme alguna de mis necesidades aquí planteadas y de compartirme sus experiencias en sus equipos de desarrollo por si alguno se ha topado con inconvenientes similares a los míos y ha llevado a cabo alguna solución alternativa.

Saludos.

miércoles, mayo 14, 2008

¿Esta versionada tu Base de Datos?

Atencion: esta entrada es para programadores... y geeks en general.

Como mencionaba Robertux en una entrada anterior:
"""¿Les ha pasado alguna vez que cuando están programando se dan cuenta que las líneas de código que acaban de agregar arruinaron el sistema y desean volver a como lo tenían el día de ayer ya que en ese entonces todavía compilaba, pero ya no se acuerdan qué fue lo último que agregaron para así poder revertirlo?

¿Les ha ocurrido que cada cierto tiempo crean una copia de la carpeta del proyecto en el que trabajan para guardarla como backup y además de que cada copia les abarca más de 10 o 20 MB de espacio en disco, al final no saben si la última versión está en la carpeta "ProyectoUltimo", "ProyectoFinal" o "ProyectoBueno" y les toca comparar las fechas de cada una?

¿Será que cuando trabajan en grupos, cada quién con su copia del proyecto y modificando los archivos que a cada quién le corresponden, al final no saben ni por dónde empezar para unir todos los archivos correctos en un único proyecto para tener la versión final y funcional?

Todas estas situaciones pasan porque no se están utilizando herramientas para el trabajo en grupo y específicamente, para el control de versiones."""

Y lo mismo podríamos decir de las Bases de Datos. Así que, developers, con esta idea en mente les pregunto:
¿Esta tu base de datos bajo control de version (cvs ó svn)?
...la respuesta a esta pregunta debería de ser (en los casos que lo amerite) SI.
¿Por que? simplemente por que:
¡la base de datos es una de las partes más criticas de cualquier aplicación! (la base de datos es tan parte de la aplicación, como el código y los modelos dentro del software)
y en la etapa de desarrollo, con varias personas trabajando en un proyecto, es muy probable que se cometan errores como los que mencionábamos al principio... o peores.
¿Y como versiono una base de datos?, bien, aquí hay un pequeño ejemplo:

Escenario de trabajo:
Gestor de Base de Datos: MySQL.
Repositorio SVN: Google Code.
Herramientas a usar (multiplataforma): SVN y MySQL (dump).
Para versionar una base de datos en mysql, basta con versionar el dump de la base de datos. Y el proceso de versionado ("Commit" y "Update" de cambios) y restauración de la BD se realiza con dos sencillos script (estos scripts pueden estar en una carpeta que se llame SQL y ser parte del proyecto que contenga esos scripts), uno script sera para realizar el "Commit" y otro para el "Update".

La logica del script de "Commit" es la siguiente:
1. Despues de realizar cambios significativos en la base de datos...
2. Llama a "mysqldump", y realiza un respaldo de la base de datos (con su contenido) en un archivo sql, por ejemplo:
mysqldump --single-transaction -hlocalhost -uROOT -pTOOR BASEDEDATOS > basededatos.sql

3. Luego realiza un "Commit" del archivo, asi:
svn commit -m "Dump de base de datos versionado" basededatos.sql

La logica del script de "Update" es la siguiente:
1. Realiza un "Update" invocando a svn...
svn update
2. Restauramos el dump actualizado obtenido a mysql:
mysql.exe -uROOT -pTOOR BASEDEDATOS < basededatos.sql

No hay que preocuparse por la información de Login para el svn, ya que si la carpeta en la que se invoca el script de commit o update esta agregada al repositorio, svn crea una carpeta llamada ".svn" que contiene la información de login (y otras cosas).
Como les mencione, esa es la lógica, si yo hago un cambio a la base de datos, hago el commit, y si hay cambios (o antes de una sesión de trabajo) hago el update.

Si esta entrada te pareció útil, aquí hay algunas reglas para trabajar con bases de datos que deberías de leer.

Espero que esto les sirva para facilitar su trabajo de desarrollo de software, ¡Saludos!


¿Esta versionada tu Base de Datos?

Atencion: esta entrada es para programadores... y geeks en general.

Como mencionaba Robertux en una entrada anterior:
"""¿Les ha pasado alguna vez que cuando están programando se dan cuenta que las líneas de código que acaban de agregar arruinaron el sistema y desean volver a como lo tenían el día de ayer ya que en ese entonces todavía compilaba, pero ya no se acuerdan qué fue lo último que agregaron para así poder revertirlo?

¿Les ha ocurrido que cada cierto tiempo crean una copia de la carpeta del proyecto en el que trabajan para guardarla como backup y además de que cada copia les abarca más de 10 o 20 MB de espacio en disco, al final no saben si la última versión está en la carpeta "ProyectoUltimo", "ProyectoFinal" o "ProyectoBueno" y les toca comparar las fechas de cada una?

¿Será que cuando trabajan en grupos, cada quién con su copia del proyecto y modificando los archivos que a cada quién le corresponden, al final no saben ni por dónde empezar para unir todos los archivos correctos en un único proyecto para tener la versión final y funcional?

Todas estas situaciones pasan porque no se están utilizando herramientas para el trabajo en grupo y específicamente, para el control de versiones."""

Y lo mismo podríamos decir de las Bases de Datos. Así que, developers, con esta idea en mente les pregunto:
¿Esta tu base de datos bajo control de version (cvs ó svn)?
...la respuesta a esta pregunta debería de ser (en los casos que lo amerite) SI.
¿Por que? simplemente por que:
¡la base de datos es una de las partes más criticas de cualquier aplicación! (la base de datos es tan parte de la aplicación, como el código y los modelos dentro del software)
y en la etapa de desarrollo, con varias personas trabajando en un proyecto, es muy probable que se cometan errores como los que mencionábamos al principio... o peores.
¿Y como versiono una base de datos?, bien, aquí hay un pequeño ejemplo:

Escenario de trabajo:
Gestor de Base de Datos: MySQL.
Repositorio SVN: Google Code.
Herramientas a usar (multiplataforma): SVN y MySQL (dump).
Para versionar una base de datos en mysql, basta con versionar el dump de la base de datos. Y el proceso de versionado ("Commit" y "Update" de cambios) y restauración de la BD se realiza con dos sencillos script (estos scripts pueden estar en una carpeta que se llame SQL y ser parte del proyecto que contenga esos scripts), uno script sera para realizar el "Commit" y otro para el "Update".

La logica del script de "Commit" es la siguiente:
1. Despues de realizar cambios significativos en la base de datos...
2. Llama a "mysqldump", y realiza un respaldo de la base de datos (con su contenido) en un archivo sql, por ejemplo:
mysqldump --single-transaction -hlocalhost -uROOT -pTOOR BASEDEDATOS > basededatos.sql

3. Luego realiza un "Commit" del archivo, asi:
svn commit -m "Dump de base de datos versionado" basededatos.sql

La logica del script de "Update" es la siguiente:
1. Realiza un "Update" invocando a svn...
svn update
2. Restauramos el dump actualizado obtenido a mysql:
mysql.exe -uROOT -pTOOR BASEDEDATOS < basededatos.sql

No hay que preocuparse por la información de Login para el svn, ya que si la carpeta en la que se invoca el script de commit o update esta agregada al repositorio, svn crea una carpeta llamada ".svn" que contiene la información de login (y otras cosas).
Como les mencione, esa es la lógica, si yo hago un cambio a la base de datos, hago el commit, y si hay cambios (o antes de una sesión de trabajo) hago el update.

Si esta entrada te pareció útil, aquí hay algunas reglas para trabajar con bases de datos que deberías de leer.

Espero que esto les sirva para facilitar su trabajo de desarrollo de software, ¡Saludos!


3 reglas al trabajar con Bases de Datos

Aquí presento algunas reglas para trabajar con bases de datos:

Regla 1: Nunca uses un solo servidor de bases de datos para todo el trabajo de desarrollo (exacto, nada de bases de datos centralizadas).

La conveniencia de trabajar con un servidor centralizado de bases de datos es tentadora. Todos los desarrolladores se conectan a una sola base de datos que pueden probar y cambiar. Este servidor funcionara como el Anillo Único de Sauron... y todos los cambios que se den, se reflejaran inmediatamente a todos los miembros del equipo de desarrollo. Es más, es tan convincente la idea de usar un servidor centralizado, que este la gente lo usa como repositorio de datos de prueba.

"Imagen: Gollum con el Anillo"

Pero, como muchas conveniencias en el desarrollo de software (y así de engañoso y malévolo como el Anillo Único), usar una sola base de datos para todo el equipo, funciona como un pozo de brea... si, como en el que murieron tantos dinosaurios :P.

"Imagen: Pozo de Brea"

Todos los desarrolladores están tentados a cambiar los tipos de datos en algún momento, y los mas probable es que así sea, pero el cambio que un desarrollador puede hacer en la base de datos... veamos que sucede, cuando todo sale mal... estos son los pasos al pozo de brea:
  1. Un desarrollador modifica un tipo de dato en la base de datos (o peor, una tabla entera... o varias).
  2. El cambio probablemente provocara un error en mi código (ya no puedo compilar mi parte).
  3. Esto implica que tengo que hacer cambios en mi código para que todo funciona como antes.
  4. O tengo que esperar a que el desarrollador que modifico la base de datos haga un "Commit" de su código para que altere el mio... y ver si funciona con lo que el hizo.
  5. Pueda que su "Commit" altere o no mi código.
  6. Si no lo altera, y ahora YO tendré que ver que $%&&/$ altero el tipo, para que mi código funcione (¿cuanto tiempo perdí ya?).
  7. Es posible también que el tipo diga después: "bueno, me equivoque, solo estaba probando...".
  8. Ahora hay que regresar a la versión anterior del software, perder horas de cambios y ajustes, y realizar el proceso, cada vez que alguien disponga hacer el paso 1.
Ademas desarrollar con una base de datos remota es LENTOOOOOOO...

"Imagen: Maldito desarrollador, ¡cambiaste todas las tablas sin avisar!"


Regla 2: Siempre ten una sola y respetada fuente para el esquema de tu base de datos (alguien se encarga de mantener y liberar la base de datos para todos).

Idealmente, esta única fuente sera tu control de versiones ( ver la regla #3). Considere el siguiente entre dos desarrolladores, Pedro y Juan:

Pedro: Es tiempo para comenzar a probar la aplicación, y depurar los errores. ¿Copiamos la base de datos de la maquina de José, o usamos la base de datos de Luis?

Juan: Ummmmmmmm, no recuerdo cual es la base de datos mas reciente (u oficial, o actualizada)

Pedro: Shit... (se pone a llorar).

Todo mundo debería de saber donde esta el ultimo esquema de la base de datos, y también es el derecho de los desarrolladores tener una experiencia sin problema para obtenerla y usarla en su maquina de trabajo. Yo desarrollador quiero caminar a mi estación de trabajo, obtener la ultima versión de la base de datos por medio de cvs ó svn, y trabajar transparentemente con ella, sin preocuparme por nada más que hacer mi trabajo.


Regla 3: Siempre versiona tu base de datos.

Hay muchas maneras de versionar una base de datos, pero el objetivo principal es propagar los cambios, probar y liberar la base de datos en una manera controlada y consistente. Un segundo objetivo es poder regresar y recrear la base de datos de algún momento anterior. Este segundo objetivo es particularmente importante si se produce software para clientes. Si alguien tiene un bug (error) en la versión 1.00.3.4 de tu aplicación (y tu vas por la versión 2.00.5.0) tienes que ser capaz de recrear la aplicación y su base de datos para esa versión, para poder darle soporte técnico al cliente o a los clientes que tengan esa versión.

Respeta estas reglas, y tu desarrollo de software sera muchísimo mas sencillo y menos traumatico.

¡Saludos!


3 reglas al trabajar con Bases de Datos

Aquí presento algunas reglas para trabajar con bases de datos:

Regla 1: Nunca uses un solo servidor de bases de datos para todo el trabajo de desarrollo (exacto, nada de bases de datos centralizadas).

La conveniencia de trabajar con un servidor centralizado de bases de datos es tentadora. Todos los desarrolladores se conectan a una sola base de datos que pueden probar y cambiar. Este servidor funcionara como el Anillo Único de Sauron... y todos los cambios que se den, se reflejaran inmediatamente a todos los miembros del equipo de desarrollo. Es más, es tan convincente la idea de usar un servidor centralizado, que este la gente lo usa como repositorio de datos de prueba.

"Imagen: Gollum con el Anillo"

Pero, como muchas conveniencias en el desarrollo de software (y así de engañoso y malévolo como el Anillo Único), usar una sola base de datos para todo el equipo, funciona como un pozo de brea... si, como en el que murieron tantos dinosaurios :P.

"Imagen: Pozo de Brea"

Todos los desarrolladores están tentados a cambiar los tipos de datos en algún momento, y los mas probable es que así sea, pero el cambio que un desarrollador puede hacer en la base de datos... veamos que sucede, cuando todo sale mal... estos son los pasos al pozo de brea:
  1. Un desarrollador modifica un tipo de dato en la base de datos (o peor, una tabla entera... o varias).
  2. El cambio probablemente provocara un error en mi código (ya no puedo compilar mi parte).
  3. Esto implica que tengo que hacer cambios en mi código para que todo funciona como antes.
  4. O tengo que esperar a que el desarrollador que modifico la base de datos haga un "Commit" de su código para que altere el mio... y ver si funciona con lo que el hizo.
  5. Pueda que su "Commit" altere o no mi código.
  6. Si no lo altera, y ahora YO tendré que ver que $%&&/$ altero el tipo, para que mi código funcione (¿cuanto tiempo perdí ya?).
  7. Es posible también que el tipo diga después: "bueno, me equivoque, solo estaba probando...".
  8. Ahora hay que regresar a la versión anterior del software, perder horas de cambios y ajustes, y realizar el proceso, cada vez que alguien disponga hacer el paso 1.
Ademas desarrollar con una base de datos remota es LENTOOOOOOO...

"Imagen: Maldito desarrollador, ¡cambiaste todas las tablas sin avisar!"


Regla 2: Siempre ten una sola y respetada fuente para el esquema de tu base de datos (alguien se encarga de mantener y liberar la base de datos para todos).

Idealmente, esta única fuente sera tu control de versiones ( ver la regla #3). Considere el siguiente entre dos desarrolladores, Pedro y Juan:

Pedro: Es tiempo para comenzar a probar la aplicación, y depurar los errores. ¿Copiamos la base de datos de la maquina de José, o usamos la base de datos de Luis?

Juan: Ummmmmmmm, no recuerdo cual es la base de datos mas reciente (u oficial, o actualizada)

Pedro: Shit... (se pone a llorar).

Todo mundo debería de saber donde esta el ultimo esquema de la base de datos, y también es el derecho de los desarrolladores tener una experiencia sin problema para obtenerla y usarla en su maquina de trabajo. Yo desarrollador quiero caminar a mi estación de trabajo, obtener la ultima versión de la base de datos por medio de cvs ó svn, y trabajar transparentemente con ella, sin preocuparme por nada más que hacer mi trabajo.


Regla 3: Siempre versiona tu base de datos.

Hay muchas maneras de versionar una base de datos, pero el objetivo principal es propagar los cambios, probar y liberar la base de datos en una manera controlada y consistente. Un segundo objetivo es poder regresar y recrear la base de datos de algún momento anterior. Este segundo objetivo es particularmente importante si se produce software para clientes. Si alguien tiene un bug (error) en la versión 1.00.3.4 de tu aplicación (y tu vas por la versión 2.00.5.0) tienes que ser capaz de recrear la aplicación y su base de datos para esa versión, para poder darle soporte técnico al cliente o a los clientes que tengan esa versión.

Respeta estas reglas, y tu desarrollo de software sera muchísimo mas sencillo y menos traumatico.

¡Saludos!


miércoles, marzo 26, 2008

Resumen de Cómo Trabajar con Subversion

"Logo Oficial de TortoiseSVN"

Como montar un servidor de Subversion requiere algo de información sobre servidores y requiere tener acceso a uno también, es mejor utilizar un hosting gratuito como Sourceforge o Google Code. Les recomiendo Google Code por su simplicidad y facilidad de uso. Luego de esto, descargan el cliente adecuado para su sistema operativo, cabe mencionar que Subversion ni sus clientes no están sujetos a un lenguaje de programación en específico. Mas aún, además de código fuente, es posible almacenar en el repositorio archivos de cualquier tipo, tomando en cuenta que los que mejor se administran son los archivos derivados del texto plano, como lo son los archivos de código fuente debido a su facilidad y universalidad de edición y manipulación.

  1. Creen un proyecto en algún servidor como los mencionados anteriormente o monten el suyo propio.
  2. Creen una carpeta o seleccionen la carpeta donde se encuentra su proyecto. Desde TortoiseSvn, clic derecho y seleccionar la opción Import. Con esto subirán al repositorio la primera revisión (versión) de su proyecto.
  3. Creen una carpeta aparte donde descargar y almacenar la copia de trabajo. Con Tortoise, Clic derecho a la carpeta y seleccionar Checkout. Aunque esto es exactamente lo que tenían en la carpeta original del proyecto, esta nueva copia denominada copia de trabajo o working copy ya está controlada para poder guardar en el repositorio sus posibles versiones. Cada miembro del grupo realizará este paso para obtener su propia copia de trabajo y modificarla localmente poniéndose de acuerdo sobre qué archivos modificará cada uno.
  4. Cuando cada miembro del grupo haya hecho modificaciones relevantes al proyecto, este puede guardar la nueva revisión dando clic derecho a la carpeta que almacena la copia de trabajo y seleccionando Commit. De esta manera se crea una nueva versión (revisión) del proyecto con los cambios que este realizó y siempre será posible volver a una revisión anterior por si fuera necesario. Es posible también solo hacer commit a un grupo seleccionado de archivos en lugar de todo el proyecto.
  5. Hay que avisar a los demás miembros que se han realizado cambios de manera que ellos se actualicen a la nueva revisión, dando clic derecho sobre la carpeta (o algunos archivos seletos) y seleccionando la opción Update. Esto no significa que perderán los cambios que cada uno haya realizado en su copia local. Si los archivos modificados en la nueva versión no habían sido tocados en la copia local de cada uno, estos permanecerán intactos, de lo contrario se creará un conflicto y el cliente almacenará temporalmente una copia tanto de la versión actual en el repositorio como de su copia local para cada archivo en conflicto para que después se seleccionen los archivos (o parte de estos) que realmente formarán la última versión y de esta forma, resolver el conflicto.
  6. Si se desea volver a una revisión anterior, clic derecho a la carpeta del proyecto y se selecciona Update to Revision donde se especifica a qué revisión se desea regresar. Cabe destacar que por cada revisión, el servidor le asigna un número correlativo y la fecha, además de un comentario o ChangeLog por parte del autor de los cambios, de manera que sea más facil a la hora de decidir a cuál revisión es necesario regresar.
  7. Para volver a iniciar el proyecto desde una revisión anterior, es posible crear una rama partiendo desde una revisión específica, lo cual también ayuda a tener múltiples formas del proyecto sin perder las actualizaciones de las versiones de cada uno. Para ello, hay que hacer un checkout de una revisión en particular y con ella crear la rama dándole clic derecho a la carpeta y seleccionando la opción Branch/Tag.

Por supuesto, los grandes y excelsos usuarios de Linux, acostumbrados a lidiar con la consola y a leer los manuales de los comandos, no necesitan que se les dé una explicación paso a paso de lo que tienen que hacer así que lo único que les adelanto es:
  1. apt-get install subversion subversion-tools
  2. man subversion
  3. man svn
Un usuario Linux sabrá como seguir desde acá.

Resumen de Cómo Trabajar con Subversion

"Logo Oficial de TortoiseSVN"

Como montar un servidor de Subversion requiere algo de información sobre servidores y requiere tener acceso a uno también, es mejor utilizar un hosting gratuito como Sourceforge o Google Code. Les recomiendo Google Code por su simplicidad y facilidad de uso. Luego de esto, descargan el cliente adecuado para su sistema operativo, cabe mencionar que Subversion ni sus clientes no están sujetos a un lenguaje de programación en específico. Mas aún, además de código fuente, es posible almacenar en el repositorio archivos de cualquier tipo, tomando en cuenta que los que mejor se administran son los archivos derivados del texto plano, como lo son los archivos de código fuente debido a su facilidad y universalidad de edición y manipulación.

  1. Creen un proyecto en algún servidor como los mencionados anteriormente o monten el suyo propio.
  2. Creen una carpeta o seleccionen la carpeta donde se encuentra su proyecto. Desde TortoiseSvn, clic derecho y seleccionar la opción Import. Con esto subirán al repositorio la primera revisión (versión) de su proyecto.
  3. Creen una carpeta aparte donde descargar y almacenar la copia de trabajo. Con Tortoise, Clic derecho a la carpeta y seleccionar Checkout. Aunque esto es exactamente lo que tenían en la carpeta original del proyecto, esta nueva copia denominada copia de trabajo o working copy ya está controlada para poder guardar en el repositorio sus posibles versiones. Cada miembro del grupo realizará este paso para obtener su propia copia de trabajo y modificarla localmente poniéndose de acuerdo sobre qué archivos modificará cada uno.
  4. Cuando cada miembro del grupo haya hecho modificaciones relevantes al proyecto, este puede guardar la nueva revisión dando clic derecho a la carpeta que almacena la copia de trabajo y seleccionando Commit. De esta manera se crea una nueva versión (revisión) del proyecto con los cambios que este realizó y siempre será posible volver a una revisión anterior por si fuera necesario. Es posible también solo hacer commit a un grupo seleccionado de archivos en lugar de todo el proyecto.
  5. Hay que avisar a los demás miembros que se han realizado cambios de manera que ellos se actualicen a la nueva revisión, dando clic derecho sobre la carpeta (o algunos archivos seletos) y seleccionando la opción Update. Esto no significa que perderán los cambios que cada uno haya realizado en su copia local. Si los archivos modificados en la nueva versión no habían sido tocados en la copia local de cada uno, estos permanecerán intactos, de lo contrario se creará un conflicto y el cliente almacenará temporalmente una copia tanto de la versión actual en el repositorio como de su copia local para cada archivo en conflicto para que después se seleccionen los archivos (o parte de estos) que realmente formarán la última versión y de esta forma, resolver el conflicto.
  6. Si se desea volver a una revisión anterior, clic derecho a la carpeta del proyecto y se selecciona Update to Revision donde se especifica a qué revisión se desea regresar. Cabe destacar que por cada revisión, el servidor le asigna un número correlativo y la fecha, además de un comentario o ChangeLog por parte del autor de los cambios, de manera que sea más facil a la hora de decidir a cuál revisión es necesario regresar.
  7. Para volver a iniciar el proyecto desde una revisión anterior, es posible crear una rama partiendo desde una revisión específica, lo cual también ayuda a tener múltiples formas del proyecto sin perder las actualizaciones de las versiones de cada uno. Para ello, hay que hacer un checkout de una revisión en particular y con ella crear la rama dándole clic derecho a la carpeta y seleccionando la opción Branch/Tag.

Por supuesto, los grandes y excelsos usuarios de Linux, acostumbrados a lidiar con la consola y a leer los manuales de los comandos, no necesitan que se les dé una explicación paso a paso de lo que tienen que hacer así que lo único que les adelanto es:
  1. apt-get install subversion subversion-tools
  2. man subversion
  3. man svn
Un usuario Linux sabrá como seguir desde acá.

Programemos Mejor: Subversion

"Logo Oficial de Subversion"

¿Les ha pasado alguna vez que cuando están programando se dan cuenta que las líneas de código que acaban de agregar arruinaron el sistema y desean volver a como lo tenían el día de ayer ya que en ese entonces todavía compilaba, pero ya no se acuerdan qué fue lo último que agregaron para así poder revertirlo?

¿Les ha ocurrido que cada cierto tiempo crean una copia de la carpeta del proyecto en el que trabajan para guardarla como backup y además de que cada copia les abarca más de 10 o 20 MB de espacio en disco, al final no saben si la última versión está en la carpeta "ProyectoUltimo", "ProyectoFinal" o "ProyectoBueno" y les toca comparar las fechas de cada una?

¿Será que cuando trabajan en grupos, cada quién con su copia del proyecto y modificando los archivos que a cada quién le corresponden, al final no saben ni por dónde empezar para unir todos los archivos correctos en un único proyecto para tener la versión final y funcional?

Todas estas situaciones pasan porque no se están utilizando herramientas para el trabajo en grupo y específicamente, para el control de versiones.

Los sistemas de control de versiones son muy populares, más que todo en el mundo del software libre, ya que bajo esta filosofía, los desarrolladores permiten a los demás tener acceso libre (no necesariamente gratuito) al código fuente además de los binarios o ejecutables. Por lo tanto, estos utilizan herramientas que les permiten controlar de una mejor manera el desarrollo y distribución del mismo y cómo este va cambiando a través del tiempo.

¿Qué son los Sistemas de Control de Versiones?

Un sistema de control de versiones se encarga de almacenar de la manera más apropiada los cambios que ocurren sobre un conjunto de archivos en intervalos determinados y centralizados en un repositorio. Como ejemplo de estos sistemas se encuentran CVS (Concurrent Version Control), Visual Source Safe y por supuesto, Subversion. De acá en adelante, todo el contenido se basará específicamente en Subversion.

¿Cómo Funcionan los Sistemas de Control de Versiones?

Se posee un repositorio de svn montado en un servidor local o remoto en el cual se almacenan todas las versiones, desde la inicial. Cada cliente desde su computadora descarga las revisiones que necesite del repositorio y empieza a trabajar en ellas. Cuando ha hecho los cambios, este actualiza el repositorio. Por supuesto, debido a la concurrencia es posible que las versiones de los archivos entren en conflicto si ambos clientes han hecho cambios sobre los mismos archivos. Por ejemplo si dos personas descargan uno o varios archivos y los modifican simultáneamente, el primero en actualizar no tendrá problemas pero el segundo, si ha modificado los mismos archivos, tendrá ciertas dificultades cuando desee actualizar ya que la versión original que el poseía en su computadora ya no coincide con la del servidor.

Esto se resuelve mediante el bloqueo de los archivos por parte de un cliente para que los demás no puedan modificarlo o bien, llegando a un acuerdo entre los que modificaron simultáneamente el archivo para determinar cuál merece ser la última versión. Para ello, Subversion provee herramientas que examinan el contenido de un archivo y lo comparan con otras versiones para remarcar las líneas agregadas, modificadas y/o eliminadas por parte de todos los que han modificado el archivo de manera que sea mas sencillo reconocer los cambios y decidir cuáles deben permanecer.

Tan simple como eso.

Cabe mencionar que Subversion no almacena copias enteras de cada versión almacenada sino que evalúa los cambios realizados entre una versión y otra y solo almacena estos para ahorrar espacio en el repositorio.

Existen diversos clientes de Subversion para poder descargar versiones de un repositorio y actualizarlas en base a nuestros cambios. Para Linux existe la aplicación de línea de comandos llamada Subversion y para Windows existe una denominada TortoiseSvn, ambas de licencia libre y proporcionadas por los mismos creadores del Subversion: Tigris.

Para más información sobre Subversion, pueden leer de forma gratuita el documento on-line Control de Versiones con Subversion. El cual también esta disponible a la venta en Amazon.

Programemos Mejor: Subversion

"Logo Oficial de Subversion"

¿Les ha pasado alguna vez que cuando están programando se dan cuenta que las líneas de código que acaban de agregar arruinaron el sistema y desean volver a como lo tenían el día de ayer ya que en ese entonces todavía compilaba, pero ya no se acuerdan qué fue lo último que agregaron para así poder revertirlo?

¿Les ha ocurrido que cada cierto tiempo crean una copia de la carpeta del proyecto en el que trabajan para guardarla como backup y además de que cada copia les abarca más de 10 o 20 MB de espacio en disco, al final no saben si la última versión está en la carpeta "ProyectoUltimo", "ProyectoFinal" o "ProyectoBueno" y les toca comparar las fechas de cada una?

¿Será que cuando trabajan en grupos, cada quién con su copia del proyecto y modificando los archivos que a cada quién le corresponden, al final no saben ni por dónde empezar para unir todos los archivos correctos en un único proyecto para tener la versión final y funcional?

Todas estas situaciones pasan porque no se están utilizando herramientas para el trabajo en grupo y específicamente, para el control de versiones.

Los sistemas de control de versiones son muy populares, más que todo en el mundo del software libre, ya que bajo esta filosofía, los desarrolladores permiten a los demás tener acceso libre (no necesariamente gratuito) al código fuente además de los binarios o ejecutables. Por lo tanto, estos utilizan herramientas que les permiten controlar de una mejor manera el desarrollo y distribución del mismo y cómo este va cambiando a través del tiempo.

¿Qué son los Sistemas de Control de Versiones?

Un sistema de control de versiones se encarga de almacenar de la manera más apropiada los cambios que ocurren sobre un conjunto de archivos en intervalos determinados y centralizados en un repositorio. Como ejemplo de estos sistemas se encuentran CVS (Concurrent Version Control), Visual Source Safe y por supuesto, Subversion. De acá en adelante, todo el contenido se basará específicamente en Subversion.

¿Cómo Funcionan los Sistemas de Control de Versiones?

Se posee un repositorio de svn montado en un servidor local o remoto en el cual se almacenan todas las versiones, desde la inicial. Cada cliente desde su computadora descarga las revisiones que necesite del repositorio y empieza a trabajar en ellas. Cuando ha hecho los cambios, este actualiza el repositorio. Por supuesto, debido a la concurrencia es posible que las versiones de los archivos entren en conflicto si ambos clientes han hecho cambios sobre los mismos archivos. Por ejemplo si dos personas descargan uno o varios archivos y los modifican simultáneamente, el primero en actualizar no tendrá problemas pero el segundo, si ha modificado los mismos archivos, tendrá ciertas dificultades cuando desee actualizar ya que la versión original que el poseía en su computadora ya no coincide con la del servidor.

Esto se resuelve mediante el bloqueo de los archivos por parte de un cliente para que los demás no puedan modificarlo o bien, llegando a un acuerdo entre los que modificaron simultáneamente el archivo para determinar cuál merece ser la última versión. Para ello, Subversion provee herramientas que examinan el contenido de un archivo y lo comparan con otras versiones para remarcar las líneas agregadas, modificadas y/o eliminadas por parte de todos los que han modificado el archivo de manera que sea mas sencillo reconocer los cambios y decidir cuáles deben permanecer.

Tan simple como eso.

Cabe mencionar que Subversion no almacena copias enteras de cada versión almacenada sino que evalúa los cambios realizados entre una versión y otra y solo almacena estos para ahorrar espacio en el repositorio.

Existen diversos clientes de Subversion para poder descargar versiones de un repositorio y actualizarlas en base a nuestros cambios. Para Linux existe la aplicación de línea de comandos llamada Subversion y para Windows existe una denominada TortoiseSvn, ambas de licencia libre y proporcionadas por los mismos creadores del Subversion: Tigris.

Para más información sobre Subversion, pueden leer de forma gratuita el documento on-line Control de Versiones con Subversion. El cual también esta disponible a la venta en Amazon.

Sunsetting Sr. Byte.

El Sr. Byte ha estado más de 5 años inactivo. Digamos que estaba en " code freeze ". Pero ahora es el último release. Quizas no...