22 de Febrero 2005
Ramas de desarrollo
Entre troncos y ramas anda la cosa.
Acabo de entender y llevar a la practica, el concepto de rama
de desarrollo bajo CVS.
Si bien el concepto lo tenia claro, dicha implementación no la
tenia todas conmigo.
Estoy usando para ello el tortoise como cliente, y la verdad , que hasta
que no descubri como funcionaba el tema del Update Special pues la
verdad es que no iba a ningun lado ;-)
La verdad , es que lo primero que hice para jugar con las ramas fue usar
el subversion.
Parece mentira que la gente se empeñe en decir que Windows es fácil de usar.
Con todos mis respectos, pero bajo GNU/Linux ES MUCHISIMO más fácil hacer
casi cualquier cosa.
Mira si es fácil, que para poner a correr el servidor de subversion:
svnserver -d ( como demonio ) , desde una shell.
Si encuentras algo mas sencillo que esta linea, me lo dices.
Lo que pasa, es que la gente tiene la fea costumbre de no leerse como
funcionan las cosas, o es más fácil molestar al vecino que tiene su Windows
para que nos eche una mano.
Despues, los ilusos, se creen con valor de decir que GNU/Linux es una mierda,
con perdón, cuando deberían de preguntarse, si realmente lo que son es un
completo IGNORANTE!.
En fin... a lo que ibamos.
¿ Como puedo aplicar una rama a mi proyecto y no morir en el intento ?
Normalmente, tenemos la sana costumbre de aplicar una instantanea, tag, del
estado actual, ok ?
Bien , pues la rama es 'algo similar', con la diferencia , que para podemos
estar en el tronco( HEAD ) , o en un rama 'determinada', sin ningun problema.
Asi, mientras unos usan por ejemplo, el tronco, yo puede 'derivar' parte de
mi trabajo a una rama, y seguir trabajando sin afectar al resto.
Muchas se preguntaran que sentido tiene esto, que desarrollando sobre el HEAD
y con tal de no hacer un 'commit' pues es lo mismo. Graso error.
Explicaré el porque me a llevado a experimental y llevar a la práctica el
uso de ramificaciones en el código de T-Gtk.
Como bien sabeis , GTK dispone de varias versiones, y cada version contiene
sus múltiples widgets, tambien hay funciones en unas y otras.
Como somos 2 desarrollando, Joaquim tiene las GTK 2.4 bajo XP, ya tengo las
GTK 2.6 en XP y 2000 y la 2.4 en GNU/Linux.
¿ Que pasa si introduzco código 'experimental' de la 2.6 ?
Automaticamente, Joaquim en su maquina y yo en mi GNU/LInux vamos a tener un
problema a la hora de intentar compilar las librerias de T-Gtk, porque no
encuentra funciones.
Quizas una manera elegante, tal y como he realizado en codigo de T-Gtk es usar
el chequeo de version en tiempo de compilacion, #ifdef , pero , si el
código es experimental , no creo que quede muy elegante realizarlo de esta
manera.
La solución pasa por hacer una rama en el CVS, usar la rama en el sistema
que me permita usarlo , sin interferir para nada en el desarrollo normal
de T-Gtk.
Asi, llegada la hora de que considere que este estable , fusionaré la rama
contra el tronco( HEAD ).
Al luchar entre distintas versiones de GTK+, y de momento, los dos sistemas
soportados, GNU/Linux y Windows, creo que las ramas son la mejor opcion de
ir avanzando en arreglar y experimentar sobre código muy inestable, no
afectando para nada al desarrollo de los demas miembros.
Os dejo imagen para que veais como esta quedando un fichero en concreto,
pango.c , dentro del CVS.
Podeis observar, las tags, el desarrollo principal HEAD, y la rama
'pango_under_2_6
Y tú, ¿ Ya vas haciendo el mono por las ramas ? ;-)
Para saber más sobre ramas del CVS:
http://lucas.ok.cl/Manuales-LuCAS/doc-cvsbook-es/cvsbook-html/Ramas.html