Si has dado click en este enlace es que sabes que svn ya no mola, ahora lo que "lo peta" es git (o si eres un poco alternativo mercurial). Dejando a un lado lo de seguir las modas, seguramente conozcas más de un proyecto que trabaja con subversion y es difícil cambiar la tendencia, sobretodo por la barrera que supone pasar del modelo de funcionamiento de subversion a git.
Este post no pretende ser una guía de comandos a ejecutar para usar acceder a un repositorio subversion, para eso ya hay tropecientos manuales, voy tratar de explicar qué ventajas y problemas (alguna solución también) que he encontrado trabajando de esta forma y sobretodo pretende ser una pequeña guía para aquellos que están pensando usar git.
Ventajas:
- Puedes hacer los commits intermedios que quieras. Para los somos "amigos del commit" es muy útil, porque puedes hacer commit aunque el código no esté funcionando. En subversion para evitar esto tenías que hacer una rama y trabajar en ella hasta que terminases. En este caso tienes todo el repositorio en local y símplemente esos commits se acumulan a tu repositorio local hasta que tú decidas enviarlos al servidor.
- Trabajo en ramas: en Git trabajar con ramas es mucho más ágil que en subversion, de modo que puedes trabjar en ramas locales de trabajo para ciertas tareas, pruebas.
- Rapidez: creas ramas, cambias de rama, haces commit, compruebas el log o diff de un fichero. Aún recuerdo cuando tortoise se me quedaba pillado esperando el log de un fichero... aunque las dos anteriores son interesantes, en subversion tenían solución, esta no la tiene por el modelo cliente servidor.
- Puedes usar otras utilidades de git: stash, cherry-pick, rebases, etc.
Desventajas:
- No hay tortoise, particularmente uso gitx y/o gitg que permiten sobretodo visualizar cómodamente diffs y la historia del repo. Edito: Carlos me comenta que sí existe un tortoisegit, aunque no lo he probado.
- Los rebases del demonio. Cuando quieres actualizarte (lo que sería un svn update) debes hacer un git svn rebase. Esto, en pocas palabras, coge los commits que has hecho en local, los deshace, se baja las nuevas actualizaciones que haya en el servidor y aplica esos commits de nuevo. Personalmente odio el rebase (me recuerda a los peores momentos de regreso al futuro), así que una forma de trabajar sería crear una rama, actualizar la rama que apunte al servidor subversion (a trunk posiblemente) y después mezclar (en git, claro) la rama de trabajo.
- No puedes actualizar si tienes algo modificado en local. Con el subversion tradicional te hacía merge de lo que venía del repo con los cambios en local. Tienes dos opciones, o hacer commit o usar stash (almacena de forma temporal esos cambios, una especie de rama rápida)
- Tienes que aprender git además de subversion. A git cuesta acostumbrarse, pero luego es más versatil y rápido, es una cuestión de inversión.
Siempre puedes empezar a probar, como siempre digo a mis pobres pupilos: "con un repositorio puedes cagarla todo lo que quieras, siempre puedes volver para atrás"
Mostrando entradas con la etiqueta subversion. Mostrar todas las entradas
Mostrando entradas con la etiqueta subversion. Mostrar todas las entradas
12.15.2008
Buenas prácticas en el uso de subversion
Aparte de saber manejar subversion, conviene saber una serie de normas básicas a seguir que facilitan bastante la vida del programador sobretodo a futuro. El futuro se puede definir como el momento en el que necesitas saber que hiciste pero no te acuerdas :).
Al grano:
- Cada commit con su tema: Intenta no mezclar código con ficheros de datos o ficheros de proyecto. Es preferible hacer muchos commits con pocas cosas que ahorrarte medio minuto en no mirar lo que tienes y subirlo todo de una vez.
- Dios los cría y ellos se juntan. Si una serie de ficheros tienen que ver con un determinado tema, por ejemplo una corrección de bug, súbelos en el mismo commit. Esto es muy útil por si luego quieres mezclar esa revisión a otra rama para corregir el bug.
- Pon comentario en todos los commits: sobra decir que comentarios del tipo "commit", "subido" no son descriptivos y no ayudan :).
- Haz TAGS. Tags para todo, cuando envíes una demo, cuando saques una release, cuando termine el año. Los tags son gratis, así que úsalos y meta-etiquetalos bien.
- Automatiza la creación de tags con cada release. Puedes usar un script parecido a este:
Además, si lo haces así podrás automatizar otras muchas cosas, como por ejemplo obtener los binarios de una release en concreto (con svn export). Puedes usar otras cosas como make, rake o lo que te de la gana.
Son unas pocas normas, aplicables a cualquier sistema de control de versiones, pero si se aplican bien mejoran mucho el uso de subversion.
Al grano:
- Cada commit con su tema: Intenta no mezclar código con ficheros de datos o ficheros de proyecto. Es preferible hacer muchos commits con pocas cosas que ahorrarte medio minuto en no mirar lo que tienes y subirlo todo de una vez.
- Dios los cría y ellos se juntan. Si una serie de ficheros tienen que ver con un determinado tema, por ejemplo una corrección de bug, súbelos en el mismo commit. Esto es muy útil por si luego quieres mezclar esa revisión a otra rama para corregir el bug.
- Pon comentario en todos los commits: sobra decir que comentarios del tipo "commit", "subido" no son descriptivos y no ayudan :).
- Haz TAGS. Tags para todo, cuando envíes una demo, cuando saques una release, cuando termine el año. Los tags son gratis, así que úsalos y meta-etiquetalos bien.
- Automatiza la creación de tags con cada release. Puedes usar un script parecido a este:
import subprocess;
SVN = 'svn'
SERVER = 'svn://localhost/agroguia/TAGS/'
version = open("scripts/instalation/version.txt").read().split(':')[-1].strip();
cmd = [SVN, 'copy', '.', SERVER + version , '-m', '"released version '+ version + '"'];
print " ".join(cmd);
subprocess.call(cmd);
Además, si lo haces así podrás automatizar otras muchas cosas, como por ejemplo obtener los binarios de una release en concreto (con svn export). Puedes usar otras cosas como make, rake o lo que te de la gana.
Son unas pocas normas, aplicables a cualquier sistema de control de versiones, pero si se aplican bien mejoran mucho el uso de subversion.
2.12.2008
Partes de un negocio: la trazabilidad
Sigo con la mini-serie con el original título "partes de un negocio". Esta vez voy a hablar de algo más cercano a lo técnico, esto es, no me basaré en suposiciones ni en historietas del abuelo :).
Los desarrolladores tenemos la costumbre de incluir errores en las aplicaciones, algunos dicen que son bugs, otros pequeños errores... por lo general cuando un error llega a una versión release quiere decir que vas a perder dinero y es proporcional a la gravedad y al número de licencias vendidas.
Pongamos un caso real, yo vendo un sistema con un software a 10 personas, todo parece funcionar perfecto, así que incluyo algunas mejoras y vendo esta nueva versión a otras 10. Pasa un año y resulta que una de esas personas te reporta un error. No pasa nada, un error aislado no es un error, es un contratiempo... sin embargo te llama otro y te cuenta lo mismo, empiezas a sospechar. Haces tus pruebas y todo parece funcionar bien, por tanto echas la culpa al usuario. Por experiencia, cuando te llaman dos personas con el mismo problema el fallo es tuyo, con lo cual ponte a buscar el error como un loco.
Comos unos hachas desarrollando reproducimos el error con los ficheros de log que hemos guardado (somos unos bestias y no se nos escapa ni un dato), vemos que es una buena metedura de pata, lo arreglamos y se lo corregimos a los clientes que han llamado.
¿Cual es el problema? De las 20 versiones que hemos vendido, cuántas tienen el error y cuantas no? Les estará funcionando mal al resto y no se han dado cuenta? solo hemos vendido 3 licencias de esa versión?
Para tener esto controlado hay dos reglas muy simples que hay que seguir:
- Congela tú código y marcalo: da igual que sea un cambio de un espacio en una línea de código, un cambio en un script de compilación... lo que sea, lo marcas y lo congelas de alguna forma (con ficheros zip, con tags en subversion, lo que sea).
Corolario: Ten siempre a mano y usables TODAS las versiones. Esto es, en cualquier momento pueden venir unos datos de una versión y tienes que sacarla del baúl y usarla. Hay que ser muy muy estricto con esto, no hay que dejar pasar ni un solo cambio sin marcar.
Corolario: todos los datos que genere la aplicación deben llevar en alguna parte la versión que corresponde.
Si no haces esto vas a perder mucho tiempo en encontrar la versión que usaste, no vas a saber si es un error propagado por diferentes versiones, es decir, estás en pelotas.
Como ejemplo yo mantengo ahora mismo 3 ramas de desarrollo mas una estable, en las ramas pruebo cosas sin desestabilizar la estable. Además, todos los datos que recojo de mis pruebas o de clientes los tengo también en el repositorio convenientemente marcadas y asociadas a las versiones de las que partieron, todo eso junto a información de las pruebas.
- Mantén un mapeo cliente-versión: parece de sentido común, pero se suele dejar porque es un coñazo. Además ten un mapeo de cosas que creas que nunca van a afectar... por ejemplo, nosotros guardamos la versión del software, marca, modelo y números de serie de todos los componenetes, marca del tractor, zona de trabajo, metros de las máquinas que tiene, cuantos tractores tiene la persona, etc, etc.
De esa forma puedes obtener una relación directa si te llama más de una persona.
Subversion es una herramienta básica para cualquier persona que use un PC y tenga que mantener versiones de datos, la gente se rie cuando le dices que usas subversion hasta para el currículum, pero es una de esas herramientas que deberían venir por defecto instaladas en el sistema operativo. Con un sistema de control de versiones con muy poco trabajo tendrás todo etiquetado, con un histórico envidiable, acceso a cualquier cosa, puedes ver el diferencial, mantener copias de seguridad... no es necesario mantener un tracker ni complejos scripts si no tienes demasiado tiempo como es mi caso. No me cansaré de hablar bien de subversion.
Los desarrolladores tenemos la costumbre de incluir errores en las aplicaciones, algunos dicen que son bugs, otros pequeños errores... por lo general cuando un error llega a una versión release quiere decir que vas a perder dinero y es proporcional a la gravedad y al número de licencias vendidas.
Pongamos un caso real, yo vendo un sistema con un software a 10 personas, todo parece funcionar perfecto, así que incluyo algunas mejoras y vendo esta nueva versión a otras 10. Pasa un año y resulta que una de esas personas te reporta un error. No pasa nada, un error aislado no es un error, es un contratiempo... sin embargo te llama otro y te cuenta lo mismo, empiezas a sospechar. Haces tus pruebas y todo parece funcionar bien, por tanto echas la culpa al usuario. Por experiencia, cuando te llaman dos personas con el mismo problema el fallo es tuyo, con lo cual ponte a buscar el error como un loco.
Comos unos hachas desarrollando reproducimos el error con los ficheros de log que hemos guardado (somos unos bestias y no se nos escapa ni un dato), vemos que es una buena metedura de pata, lo arreglamos y se lo corregimos a los clientes que han llamado.
¿Cual es el problema? De las 20 versiones que hemos vendido, cuántas tienen el error y cuantas no? Les estará funcionando mal al resto y no se han dado cuenta? solo hemos vendido 3 licencias de esa versión?
Para tener esto controlado hay dos reglas muy simples que hay que seguir:
- Congela tú código y marcalo: da igual que sea un cambio de un espacio en una línea de código, un cambio en un script de compilación... lo que sea, lo marcas y lo congelas de alguna forma (con ficheros zip, con tags en subversion, lo que sea).
Corolario: Ten siempre a mano y usables TODAS las versiones. Esto es, en cualquier momento pueden venir unos datos de una versión y tienes que sacarla del baúl y usarla. Hay que ser muy muy estricto con esto, no hay que dejar pasar ni un solo cambio sin marcar.
Corolario: todos los datos que genere la aplicación deben llevar en alguna parte la versión que corresponde.
Si no haces esto vas a perder mucho tiempo en encontrar la versión que usaste, no vas a saber si es un error propagado por diferentes versiones, es decir, estás en pelotas.
Como ejemplo yo mantengo ahora mismo 3 ramas de desarrollo mas una estable, en las ramas pruebo cosas sin desestabilizar la estable. Además, todos los datos que recojo de mis pruebas o de clientes los tengo también en el repositorio convenientemente marcadas y asociadas a las versiones de las que partieron, todo eso junto a información de las pruebas.
- Mantén un mapeo cliente-versión: parece de sentido común, pero se suele dejar porque es un coñazo. Además ten un mapeo de cosas que creas que nunca van a afectar... por ejemplo, nosotros guardamos la versión del software, marca, modelo y números de serie de todos los componenetes, marca del tractor, zona de trabajo, metros de las máquinas que tiene, cuantos tractores tiene la persona, etc, etc.
De esa forma puedes obtener una relación directa si te llama más de una persona.
Subversion es una herramienta básica para cualquier persona que use un PC y tenga que mantener versiones de datos, la gente se rie cuando le dices que usas subversion hasta para el currículum, pero es una de esas herramientas que deberían venir por defecto instaladas en el sistema operativo. Con un sistema de control de versiones con muy poco trabajo tendrás todo etiquetado, con un histórico envidiable, acceso a cualquier cosa, puedes ver el diferencial, mantener copias de seguridad... no es necesario mantener un tracker ni complejos scripts si no tienes demasiado tiempo como es mi caso. No me cansaré de hablar bien de subversion.
Suscribirse a:
Entradas (Atom)