Subversive, cliente de Subversion para Eclipse

1
60654

Creación: 09-08-2006

Índice de contenidos

1. Introducción

En este tutorial vamos a introducirnos en el manejo de Subversive, un plugin para Eclipse que nos permite trabajar con el ampliamente extendido (y cada vez más) sistema de control de versiones Subversion (http://subversion.tigris.org/).

Subversive es un producto open source de Polarion Community (http://www.polarion.org/index.php?page=overview&project=subversive).

2. Entorno

El tutorial está escrito usando el siguiente entorno:

  • Hardware: Portátil Ahtec Signal 259M MXM (Sonoma 2.1 GHz, 2048 MB RAM, 100 GB HD).
  • Sistema Operativo: GNU / Linux, Debian Sid (unstable), Kernel 2.6.17, KDE 3.5
  • Máquina Virtual Java: JDK 1.5.0_07 de Sun Microsystems
  • Eclipse 3.2
  • Subversive 1.0.1

3. Instalación

Vamos a hacer la instalación usando el “Eclipse Update Manager”. Para ello pinchamos sobe el menú: Help –> Software Updates –> Find and Install…

Seleccionamos “Search for new features  install”, y pulsamos el botón “Next >”.

Pinchamos sobre el botón “New Remote Site…”.
Nos aparece una ventana donde pondremos el nombre del sitio donde se buscarán actualizaciones de Eclipse (podemos poner lo que queramos, por ejemplo “Polarion Subversive”), y la URL del sitio. Esta debe ser:
http://www.polarion.org/projects/subversive/download/update-site/

Vemos como nos aparece ya marcado el nuevo sitio que acabamos de añadir. Pulsamos sobre el botón “Finish”.

Nos aparece una ventana donde debemos seleccionar la actualización de Eclipse que queremos instalar. En este caso “Subversive SVN Team Provider 10.1”. Y Pulsamos sobre “Next V”.

Aceptamos la licencia y pulsamos sobre el botón “Next >”.

Pulsamos sobre “Finish” para comenzar la descarga e instalación.

Confirmamos la instalación pulsando sobre “Install All”.

Una vez terminada la instalación es conveniente reiniciar el entorno, así que pulsamos sobre el botón “Yes”.

4. Dando de alta un repositorio

Para poder usar un repositorio de Subversion lo daremos de alta en la perspectiva “SVN Repository Exploring”. Para ello podemos pinchar sobre Window –> Open Perspective –> Other…

Seleccionamos “SVN Repository Exploring” y pulsamos el botón “OK”.

Sobre la vista “SVN Repositories” pulsamos con el botón derecho del ratón y seleccionamos New –> Repository Location…

En esta pantalla configuramos la URL por la que accederemos al repositorio. Esta URL empezará por http://, svn:// o svn+ssh:// dependiendo de como esté configurado
Subversión en el servidor (habrá que consultar con nuestro administrador de Subversion).

Ponemos nuestro usuario y nuestra clave y pulsamos sobre el botón “Finish”.

Ahora podemos ver como nuestro repositorio está en la lista.

5. Trabajando con proyectos

5.1. Añadiendo un proyecto al repositorio

Lo primero que vamos a hacer es dar de alta un proyecto en el repositorio que acabamos de añadir. Para ello vamos a la perspectiva Java donde tenemos creado un pequeño proyecto de prueba.

Pulsamos con el botón derecho del ratón sobre el nombre del proyecto y seleccionamos la opción Team –> Share Project…

Seleccionamos la opción “SVN” para añadir el proyecto a un repositorio de Subversion, y pulsamos el botón “Next >”.

Seleccionamos de la lista el repositorio en el que queremos añadir el proyecto, y pulsamos sobre el botón “Next >”.

Esta ventana es muy importante ya que aquí le diremos la disposición (layout) del repositorio, y esto afecta directamente a la estructura de directorios que se va a crear.

La ventana nos presenta tres opciones, yo escojo la segunda “Use single project layout”. Con esta opción conseguimos que dentro de nuestro repositorio “autentia” se cree un directorio por cada proyecto (en este caso “autentiaProject”), y dentro de este se crearán tres directorios: trunk (donde haremos el desarrollo del día a día), branches (donde
guardaremos las ramas), y tags (donde guardaremos la versiones etiquetadas).

Para más información sobre el “layout” del proyecto, es recomendable leer http://svnbook.red-bean.com/nightly/en/svn.reposadmin.projects.html#svn.reposadmin.projects.chooselayout.

Una vez elegida la opción que nos interesa, pulsamos sobre el botón “Finish”.

Ahora nos aparece la ventana de Commit (la vamos a ver muchas veces). En este ventana se nos muestra que cambios se van a subir al repositorio. Debemos (no es estrictamente obligatorio, pero si muy buena práctica) poner un comentario que refleje los cambios que se han hecho en los ficheros que se van a subir al repositorio.

Pulsamos sobre el botón “OK” y ya tenemos el proyecto en el repositorio.

5.2. Descargando un proyecto del repositorio

Ahora vamos a hacer la operación inversa. Supongamos que nos incorporamos a un nuevo equipo de trabajo y necesitamos descargarnos del repositorio los proyectos pertinentes.

Abrimos la perspectiva “SVN Repository Exploring”, y después de dar de alta el repositorio (ver punto 2.) expandimos sus ramas hasta ver algo como:

Pinchamos con el botón derecho del ratón sobre la carpeta “trunk” (donde se hace el desarrollo del día a día), y seleccionamos la opción “Check Out”.

Ya hemos terminado, si vamos a la perspectiva Java veremos como ya tenemos en nuestro entorno el proyecto.

5.3. Haciendo commit en el repositorio de nuestros cambios locales

Como ejemplo de cambios en nuestro proyecto local vamos a ver una
modificación que implique cambio de nombre y de localización de un fichero.

Con este ejemplo se pretende ilustrar una de las capacidades, a mi parecer, más interesantes que tiene Subversion: el versionado de los metadatos.

Por el contrario, CVS no es capaz de mantener el histórico de un fichero si este cambia de nombre o de lugar. Para CVS es como si el fichero se borrara y se creara uno nuevo, con lo que se pierde todo el histórico (realmente no se pierde porque el fichero borrado siempre es recuperable, pero entre el antiguo y el nuevo no existe conexión, por lo que resulta difícil localizarlo).

Si vemos la siguiente imagen y la comparamos con la imagen del apartado anterior, se puede apreciar como la clase Foo se ha renombrado y cambiado de paquete.

En la imagen también se puede apreciar como Eclipse marca con el carácter “>” los cambios producidos en local, con respecto al repositorio.

Ahora sobre el proyecto pinchamos con el botón derecho del ratón y seleccionamos la opción Team –> Synchronize with Repository. Esto nos lleva a la perspectiva de sincronización, donde podemos hacer commit de nuestros cambios locales, o update de los cambios en el repositorio.

Si desplegamos las ramas vemos que la vista de sincronización nos marca dos cambios, el borrado de un fichero y la aparición de uno nuevo. Por ahora parece el mismo comportamiento que en el CVS, pero tengamos un poco de paciencia.

Pulsamos el icono (Commit All Outgoing Changes) más a la derecha dentro la vista de sincronización (el icono que es una flecha apuntando a un cilindro). Con este icono subimos todos los cambios que tengamos en local al repositorio.

Nos encontramos en la ya conocida ventana de “Commit”. Introducimos un comentario y pulsamos sobre el botón “OK”.

Se ve como ya no quedan cambios que subir al repositorio.

Volvemos a la perspectiva de Java, y pinchamos con el botón derecho del ratón sobre la clase FooRenombrada y seleccionamos la opción Team –> Show Resource History

En la vista “SVN Resource History” podemos ver el histórico de la clase. Se puede apreciar como Subversion mantiene el histórico a pesar del cambio de nombre y de haber cambiado de sitio la clase. De hecho en el histórico se puede ver donde estaba antes y como se llamaba.

6. Conclusiones

Gracias, según mi opinión, a la gestión transaccional de los commit (y los updates), y la capacidad para mantener el histórico de los metadatos, Subversion se convierte en un potente aliado a al hora de gestionar nuestro repositorio.

Sólo por estas dos capacidades ya merece la pena migrar de CVS a Subversion, ya que facilitan enormemente las tareas de refactorización.

Desde Autentia (http://www.autentia.com) os recomendamos el uso de este tipo de herramientas para conseguir un correcto control de los proyectos.

7. Sobre el autor

Alejandro Pérez García, Ingeniero en Informática (especialidad de Ingeniería del Software)

Socio fundador de Autentia (Formación, Consultoría, Desarrollo de sistemas transaccionales)

mailto:alejandropg@autentia.com

Autentia Real Business Solutions S.L. – “Soporte a Desarrollo”

http://www.autentia.com

 

 

1 Comentario

Dejar respuesta

Please enter your comment!
Please enter your name here