¿Qué debemos meter en el sistema de control de versiones?

 

Cuando trabajamos en proyectos que usan sistema de control de versiones, pero todavía no tenemos muy afianzado qué cosas debemos meter en dicho sistema, pueden aparecer determinados ficheros en los que nos entra la duda de si debemos meterlos o no. Por ejemplo, ¿metemos o no los ficheros de proyecto de eclipse o netbeans? ¿metemos o no las librerías externas a nuestro proyecto, como log4j, drivers de bd, etc?.  La decisión, por supuesto, depende mucho de los gustos personales de la gente que lleva el proyecto, pero también depende en parte de las herramientas que usemos que no tienen mucho que ver con el sistema de control de versiones. Voy a comentar aquí un posible criterio más o menos lógico.

En el sistema de control de versiones deben ir todos aquellos ficheros que nosotros debemos hacer o proporcionar manualmente al proyecto. No deben ir todos aquellos ficheros que se generan de forma automática.

En el primer grupo, los que nosotros generamos, están claramente los fuentes de nuestro código (los .java por ejemplo), los scripts de compilado o de arranque de la aplicación, los ficheros de configuración (properties de java), los iconos de nuestra aplicación, etc, etc. Quedarían excluidos, por ejemplo, los fuentes que genere automáticamente alguna herramienta o script a partir de otros ficheros que sí hacemos manualmente.

Es muy importante meter en el sistema de control de versiones absolutamente todo lo necesario para construir desde cero y ejecutar nuestra aplicación tal cual era en un momento dado. De nada sirve tener versiones de los fuentes si no tenemos también almacenadas las versiones correspondientes de los scripts de arranque, de los ficheros de configuración (properties) o de creación de las tablas de base de datos.

En el segundo grupo, los generados automáticamente y que no van en el sistema de control de versiones, están los ejecutables y librerías que genera nuestro proyecto. Ni siquiera tendríamos que meterlos para conservar una versión especialmente estable o buena, ya que los sistema de control de versiones suelen soportar cosas como etiquetas o ramas y bastaría con marcar los fichero que sí van con una etiqueta para ser capaces de generar ese ejecutable estupendo.

Bien, esos son los ficheros más o menos claros, pero, ¿qué hacemos con las librerías externas?. Esta decisión ya puede depender de gustos y de las herramientas que usemos. Si usamos, por ejemplo, maven, todos los desarrolladores tendrán acceso a esos jar a través de internet de forma automática y sin preocuparse en absoluto de ello, por lo que con este tipo de herramientas no es necesario en absoluto meter en el sistema de control de versiones cosas como log4j.jar, junit.jar o ojdbc14.jar. Si no usamos una herramienta de este tipo, para comodidad para los desarrolladores, debemos tener todos estas librerías accesibles de forma fácil en algún sitio y una buena opción es meterlas en el sistema de control de versiones. Normalmente metemos cada una de estas librerías una sola vez y no van a tener modificaciones. Un desarrollador nuevo tendrá todas las necesarias símplemente con hacer un checkout y los scripts de compilado sabrán dónde buscar estas librerías.

¿Y qué hacemos con los ficheros de proyecto del IDE de trabajo, como los .project, .classpath o .settings de eclipse?. Nuevamente, la decisión puede depender de gustos y de las herramientas a usar. Nuevamente, si usamos maven, el comando mvn eclipse:eclipse nos genera estos ficheros automáticamente, por lo que es cómodo generarlos para un desarrollador recién incorporado al grupo y no sería necesario meterlos en el sistema de control de versiones. Si no usamos este tipo de herramientas, podemos meter estos ficheros en el sistema de control de versiones, pero tenemos que ser muy conscientes de que pueden ser problemáticos:

  • A veces estos ficheros llevan paths absolutos, por lo que todos los desarrolladores deben sacar el proyecto en el mismo directorio absoluto en su ordenador (por ejemplo, C:\PROYECTO) y posiblemente, tener las librerías externas en el mismo path absoluto (sea dentro de control de versiones o no).
  • Si un desarrollador quiere modificar algo en su IDE que afecte a estos ficheros (por ejemplo, añadir una dependencia nueva para probar o símplemente, cambiar el nombre del proyecto porque no le gusta el oficial), debe ser muy cuidadoso para no hacer un commit de esos ficheros descuidadamente.

Si decidimos no meterlos, debemos ser conscientes de que los desarrolladores nuevos deben montar manualmente el proyecto. Y si decidimos hacer cambios "oficiales" (añadir una dependencia, por ejemplo), todos deben realizar ese cambio manualmente.

 

Entradas relacionadas:

Esta entrada ha sido publicada en CVS, Herramientas, maven y etiquetada como , , . Guarda el enlace permanente.

6 respuestas a ¿Qué debemos meter en el sistema de control de versiones?

  1. blaxter dijo:

    Las librerías solo hay que meterlas salvo que se puedan instalar de forma simple (apt-get, mvn, gem, cpan, etc… que suele ser el 99% de los casos sin exagerar) en cuyo caso habrá que ponerlo en algún README o script que configure todo. Solo sería interesante incorporarlas cuando se hace alguna modificación a éstas o se usa alguna versión parcheada o similares (lo cual no suele ser excesivamente raro).

    Los ficheros de configuración de tu IDE, rotundamente no, eso es configuración de mi sistema, no del proyecto. Los problemas que comentas son ejemplos clásicos de una mala gestión de configuración (¡¿rutas absolutas?!). Solo encontraría útil meter estos ficheros en el vcs si solo lo usas tú, pero en un proyecto de la empresa como que no.

    ps: Una pregunta, ¿trabajas en algún proyecto donde no se usa vcs?.

  2. Chuidiang dijo:

    Hola Blaxter:

    No trabajo en proyectos sin vcs, pero hay gente (y conozco más de uno) que sí lo hace y ni siquiera sabe qué es un vcs.

    En cuanto a los jars, como hemos comentado los dos, no es buena solución si dispones de otras herramientas que sean capaces de acceder a ellos fácilmente (mvn, apt-get, etc). Incluso maven con algo como archiva te permite no tener que meter en vcs las librerías parcheadas, porque puedes subirlas a archiva dejándolas accesibles para todos con maven. Pero si dependes de MUCHAS librerías externas y no dispones de ese tipo de herramientas, algo habrá que hacer para facilitar la tarea.

    En cuanto al IDE, tampoco es buena idea meterlo en vcs, pero volvemos al caso anterior. Imagina que dependes de MUCHAS librerías y que no tienes nada que te monte el proyecto fácilmente en el IDE. ¿Deben perder el tiempo todos los desarrolladores montando el proyecto la primera vez? ¿Deben perder el tiempo avisandose unos a otros y actualizándolo a mano cuando a uno de ellos se le ocurre añadir/modificar alguna dependencia?. En cuanto a rutas absolutas, estaba pensando en Together (la versión antigua cuando la usábamos, aunque no es un IDE propiamente dicho). Pone path absolutos en sus ficheros de configuración y el proyecto Together sólo se puede abrir si está ubicado en el path absoluto en que se creó.

    Se bueno.

  3. blaxter dijo:

    En el caso del «Together» (que no lo conozco), ahí el problema está en el propio IDE. Yo lo que haría sería crearme algún script para autogenerar los ficheros necesarios (y es lo que suelo hacer realmente).

    Pero bueno, también es verdad que si sabes que todo el mundo va a usar herramienta X (e.g.: eclipse), hay que dejarse de chorradas y ser pragmáticos :).

    En todo caso, creo que esos «.project», «.loadpath» o los equivalentes a otro IDE son fácilmente generables siempre y cuando se tengan instrucciones/información sobre el proyecto en si. Siempre es mejor dejar un README comentando las cosas (inusuales) que dejarlo implícito en un fichero de configuración del IDE que al cabo de 2 meses ya nadie sabrá qué es lo que tiene (ni quien lo generó por primera vez).

    Aparte que todo esto en la práctica suele ser trivial (en proyectos java con maven, como dices mvn eclipse:eclipse, en proyectos c++ cmake hace esta función, y en definitiva en cada plataforma tienes equivalentes :D).

  4. Yo soy un adicto a Maven y, como tal, suelo eliminar cualquier fichero de configuración del IDE con el siguiente comentario en el commit «No me importa cuál es tu IDE». Poco a poco, a base de perseverancia y de svn:ignore…

  5. Dani Latorre dijo:

    En una ocasión estuve trabajando en un proyecto donde el departamento de sistemas no nos dejaba subir los .jar(o cualquier otro binario), y con eso de que «no hay tiempo» tampoco me dejaron meter maven :S.

    Teníamos que ir a buscar/dejar las dependencias a un directorio compartido de un miembro del equipo, que ya era un engorro cuando veías que tenías nuevas dependencias… ¿Pero qué pasaba si un día faltaba ese miembro del equipo? XD, pues tocaba avisar que en tu máquina dejabas compartido un nuevo jar. Vamos, un dolor de muelas :S

    Sobre los ficheros de configuración del IDE, pues pienso que depende, si todo el equipo usa el mismo no lo veo mal, si se usan diferentes creo que es preferible no hacerlo.

    Y sí, hay gente que no tiene ni pajolera idea de qué es un VCS, también conozco algunos que no lo «consideran necesario» por trabajar sólos o en equipos muy pequeños… pero claro, lo conocen de oídas y nunca han probado a trabajar con un VCS… en fin

  6. Marc Pujol dijo:

    Es muy importante meter en el sistema de control de versiones absolutamente todo lo necesario para construir desde cero y ejecutar nuestra aplicación tal cual era en un momento dado.

    Puedes construir desde cero y ejecutar la aplicación tal cual era en un momento dado sin las librerías externas? No, y eso para mi responde a la cuestión.

    Si usamos, por ejemplo, maven, todos los desarrolladores tendrán acceso a esos jar a través de internet de forma automática y sin preocuparse en absoluto de ello […]

    Esto sólo funciona hasta que algo falla (repositorio de librerías caído, librería eliminada por error, etc.). Las cosas que van juntas deberían estar juntas: sino es como tener un sistema de bases de datos con datos duplicados.

    Imaginad una base de datos donde el nombre del cliente aparece tanto en la tabla «clientes» como en la «direcciones». Evidentemente, nuestro framework mega-chachi se encarga (sin transacciones!) de actualizar uno cuando cambia el otro. Todo funciona, ¿no? … hasta el día que falla. En este caso no sería muy dura la consecuencia, pero con las liberías te puedes encontrar que el programa no funciona y no tienes manera de recuperarla.

Deja una respuesta

Tu dirección de correo electrónico no será publicada.

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.