The Helder Post

CVS en Eclipse

Si, si, ya se, “Subversion es mejor”, “Mercurial es más cool”, … ya, claro, pero estadísticamente en los últimos 3 años solo me he encontrado con dos proyectos muy chicos (no más de 2 meses) que no usaban CVS. Además, lleváis razón; existen opciones más fáciles de manejar. Así que si vemos algo un poco menos flexible habremos pasado ya el trago amargo.

El Concurrent Versions System (CVS), también conocido como Concurrent Versioning System, es una aplicación informática que implementa un sistema de control de versiones: mantiene el registro de todo el trabajo y los cambios en los ficheros (código fuente principalmente) que forman un proyecto (de programa) y permite que distintos desarrolladores (potencialmente situados a gran distancia) colaboren.

El primer paso es compartir el proyecto creado en Eclipse. Como todo, click derecho y “Team -> Share Project”.

Luego podemos ingresar los datos del nuevo repositorio al cual accederán nuestros colegas para entre todos colaborar con el proyecto.

Por último registramos los cambios con la acción “commit”.

Una vez tengamos el proyecto en el repositorio, el resto es simple uso del click derecho sobre el proyecto o sobre algún fichero particular de este:

• Team > Update: verifica si existen ficheros modificados en el repositorio.
• Team > Commit: guarda los cambios en el repositorio.
• Team > Synchronize with Repository: muestra las diferencias entre el espacio de trabajo y el repositorio.
  
  
  Estas diferencias, en la mayor parte de los casos, se pueden resolver editando las incongruencias entre versiones.
  
  

Cuando un proyecto está iniciado y publicado en un Repositorio CVS, podemos importarlo para verlo, modificarlo o colaborar en el desarrollo. Para ello seleccionamos la opción “File > Import”, a continuación seleccionamos la opción “Checkout Projects from CVS” e introducimos los datos del repositorio.

Esto cubre lo básico de CVS y Eclipse. Pero cuando los equipos son un tanto más grandes y se encuentran trabajando en partes de software distintas, suele darse el caso de particionar el trabajo en ramas, donde cada grupo de desarrollo trabaja en una rama distinta. El problema suele ocurrir luego al hacer “merge” de las ramas. En ese proceso de unión, Eclipse despliega la interfaz de diferencias entre versiones ofreciendo la posibilidad de editar los cambios y almacenar el resultado de la unión en otra rama o head.

Tal vez mi función preferida en todos estos casos sea “Team -> Show history”, que muestra todos los cambios realizados sobre el fichero y almacenados en el repositorio en una línea de tiempo.

Esta vista nos puede ahorrar mucho trabajo al identificar versiones estables, responsables, fechas de subidas, estados (para TDD y Kanban, suele ser una bendición), comentarios y etiquetas.

Eclipse… o lo amas o lo odias

Pos si, esa ha sido mi relación con Eclipse a lo largo de los años. Mucho odio, pero desde que llegué a España no he podido dejar de usarlo ya que es la herramienta de referencia para proyectos Java. Ahora que Netbeans se ha estancado un poco, pos no me queda de otra que hacer las paces con la herramienta que predijo desde un principio que a todo ‘Sol’ le llega su ‘Oráculo’ [y no me simpatiza que haya tenido razón].

Dolores aparte y para poner las cosas en contexto, Eclipse se puede descargar de http://www.eclipse.org/ en sus distintas versiones para cada necesidad. Su estructura base está conformada por ‘perspectivas’, dependiendo de lo que se desee Eclipse se comportará de formas distintas, ofreciendo las herramientas de uso frecuente en sus ‘vistas’.

Sus herramientas y perspectivas se pueden ampliar con los comúnmente denominados ‘plugins’ de Eclipse. Estos plugins pueden buscarse desde la web http://marketplace.eclipse.org/, y su instalación es tan simple como copiar la url de descarga que nos ofrece la página y agregarla a nuestra lista de actualizaciones de software. Hay mucho material para instalar y probar, muchas veces quedamos con más de una herramienta para editar un xml, hacer pruebas de cobertura o generar pruebas, así que frecuentemente nos toca hacer mantenimiento de los plugins instalados.

Habiendo colocado las cosas en contexto, en los próximos post estaré usando Eclipse para mostrar la integración con repositorios de versiones, desarrollo SE y EE, y algunas cosillas más. Quien quita y acabe bien la cosa…