Ingresar:

Pablo Azero :: Blog :: Evaluación de software para control de versiones

July 07, 2007

user icon
Pablo Azero

Evaluación de software para control de versiones

Es indudable que para cualquier tipo de desarrollo serio hoy dia se necesita un software de control de versiones, sobre todo si uno trabaja en grupo (aunque no únicamente). Hasta hace algún tiempo las posibilidades de elección eran pocas, uno de los viejitos como RCS o uno más nuevito como CVS. Hoy en dia sin embargo han surgido muchas alternativas, sobre todo en el mundo libre y pensando en grupos de trabajo con integrantes distantes físicamente: subversion, mercurial, darcs, bazaar, etc. En una publicación del blog de Ian Clatworthy se encuentran algunos elementos para tomar en cuenta a la hora de tomar una decisión. En el desenlace final, Ian nos muestra una preferencia clara, pero si uno se hace al de la vista gorda, en el post se puede encontrar elementos más generales para analizar y aprender las características de estas útiles herramientas, sobre todo de cara al futuro.

Palabras clave: control de versiones, evaluación

Enviado por Pablo Azero


Comentarios

  1. Tienes razón es indudable que para el desarrollo de software (aunque no es excluyente) siempre es necesario utilizar un sistema de control de versiones. Incluso si trabajas sólo, aunque a este último método le llaman generalmente Local VCS.

    A la lista que mencionas, yo le añadiría el HCV (Human Control Version), de seguro ha sido el que ha dado lugar al nacimiento de los modernos sistemas de control de versiones que ahora tenemos a nuestro alcance.

    En que consiste?

    Bueno, he visto como se trabaja con eso en una empresa de desarrollo de software en la que estuve por corto tiempo, va de la siguiente forma:

    • Cada miembro del equipo desarrolla localmente en el código del proyecto entero.
    • Al desarrollar debe de anotar con tags (manuales) que parte del código se está modificando (Usando Fecha y código de usuario generalmente).
    • Cada desarrollador copia los archivos que ha modificado a un directorio compartido.
    • Llega la fecha de la fusión de código (esto era interesante),  se elegía a un miembro del equipo para que éste haga la fusión (merge) de los archivos que cada desarrollador había subido a ese directorio compartido. Esta persona era el motor del merge, ella obtenía todo el código de la última version del código (update) e iba comparando archivo por archivo viendo los cambios definidos en los tags que cada desarrollador había definido en los archivos que copió (merge).
    • Después de un arduo trabajo, se tenía un proyecto con todos los cambios aplicados (commit).
    • Ahora venía la prueba final, que era ver si no se había olvidado pegar una porción de código en el proyecto principal o algún desarrollador se había olvidado copiar algún archivo que había modificado en el lapso. Para detectar eso, se compilaba todo el proyecto y testeaba todo.
    • El proceso se repetía aproximadamente cada semana, y se sorteba (si mal no recuerdo) a la siguiente persona que haría el merge!


    Lo anterior es verídico, claro que no puedo dar nombres, por razones obvias. Me imagino que a estas alturas ellos habrán dejado su HCV y migrado a sistemas de control de versiones mas modernas ;-)

     

    user iconFernando Javier Montaño Torrico on Saturday, 07 July 2007, 00:08 BOT # |

  2. Algo que viene al  caso, que vcs distribuido es más distribuido: http://changelog.complete.org/posts/528-Whose-Distributed-VCS-Is-The-

    Aunque no soy programador profesional, uso el control de versiones para muchas cosas... incluso archivo de configuración.  Desde que conocí mercurial hace tiempo ya no lo cambio por nada, un motivo importante es que el branching es cheap (barato?), osea que ocupa muy poco espacio. Esto es importante, por ejemplo el repositorio ajayu son más de 100Mb y existen proyectos usando mercurial de más de 1Gb.

    Para el caso de ajayu tengo los siguientes repositorios:

    • elgg_svn: que es un mirror en mercurial del repositorio subversion del proyecto principal
    • elgg_ajayu: derivado de elgg_svn que incluye todas las mejoras y correciones aplicables a la versión "vainilla", de aquí es donde salen los parches hacia el proyecto principal 
    • elgg_plugins: los plugins de terceros
    • mod_*: los módulos desarrollados, que son hecho bajo elgg_svn para que otras personas puedan usarlo en elgg
    • ajayu: es un merge de los anteriores, además de incluir cambios específicos para ajayu 

    Cuando quiero desarrollar una nueva funcionalidad, o un plugin, entonces hago un clon de elgg_ajayu, luego en caso de ser plugin lo pongo en su propio repositorio, al final lo pruebo bajo elgg_svn para poder enviarlo a elgg.org.

    #1 que tortura...

    user iconRho on Saturday, 07 July 2007, 16:47 BOT # |

  3. Bueno, de hecho también necesitas un HVC aunque uses un sistema de control de versiones, aunque no tan sofisticado como el que Fernando ha tenido que sufrir. El uso de la herramienta inmediatamente no te convierte en una persona organizada y capaz de hacer el control de las versiones disciplinadamente, aunque muchos programadores por su carácter ya poseen suficientes caracerísticas de organización. La sincronización del trabajo de grupo suele requerir un poco de discusión y la definición de criterios comunes de organización. En la wikipedia encontramos un diccionario básico de los términos usados para el control de versiones.

    user iconPablo Azero on Sunday, 08 July 2007, 11:28 BOT # |

Debes iniciar sesión para enviar un comentario.