Tutorial Eclipse y SVN

Tutorial Inicial Eclipse / SVN
Introducción
El objetivo de este documento es presentar varias herramientas que utilizamos comunmente en
los proyectos de desarrollo de software.
Las herramientas que vamos a comentar son:


SVN
Eclipse
¿Qué es SVN?
SVN o mejor dicho Subversion es un sistema de control de versiones o SCM, permite la
integración y el trabajo de un grupo de personas distribuido. Además de sincronizar y distribuir
versiones de archivos, permite el manejo de versiones de los mismos.
Esto nos facilita la forma de trabajo y nos permite que múltiples personas interactúen sobre los
mismos archivos, por supuesto con cierto cuidado.
Trabaja teniendo una copia local (working copy) donde el usuario actúa sobre los archivos
como si fueran archivos comunes, y una copia de los mismos en el servidor. En el servidor se
mantienen todas las versiones, permitiendo volver a cualquiera de ellas, las versiones se aplican a nivel
de archivos, o sea puedo traerme la versión x de un archivo y la x+n de otro.
El usuario trabaja sobre su working copy, generando cambios sobre archivos, creando nuevos o
borrando archivos. Una vez que considera que tiene cambios que quiere propagar a todo el equipo hace
un commit, que es impactar los cambios de sus archivos en el servidor generando una nueva versión
(revision).
Cuando hacer commit (o commitear en spanglish) va a depender de como trabaja cada grupo, se
considera políticamente correcto no commitear cosas que rompan todo el proyecto, pero tampoco es
políticamente correcto commitear cada 6 meses ya que es más que probable que se modifiquen los
mismos archivos por varios usuarios.
En caso de que se modifique el mismo archivo en dos usuarios distintos, el svn trata de hacer un
merge (integrar o mergear los archivos) pero si no puede porque tocaron las mismas líneas o parecidas
va a generar un conflicto que se debe resolver a mano.
Existen clientes y servidores de Subversion para distintas plataformas, todas pueden interactuar
entre sí, básicamente para este tutorial se van a mostrar todos los pasos necesario. Pero es posible usar
clientes visuales como TortoiseSVN (para Windows) o RapidSVN (para Linux). TortoiseSVN tiene el
beneficio de integrarse con el explorador de archivos, permitiendo hacer las operaciones con un click
del botón derecho.
Además de los clientes standalone existen plugins para integrar SVN con los IDE más
utilizados, no solo de Java, sino de casi cualquier cosa.
Subversion: http://subversion.tigris.org/
TortoiseSVN: http://tortoisesvn.net/
Subclipse (plugin de Eclipse): http://subclipse.tigris.org/
1 - Como crear un repositorio
Para la gestión de un proyecto vamos a necesitar un servidor de SVN. Para esto hay varias
posibilidades, por un lado se puede tener un servidor svn en un servidor privado (en el cual se instala el
servidor de SVN y se le da acceso a los participantes del proyecto), o bien, se puede utilizar un servidor
gratuito como http://www.xp-dev.com/ (en internet hay muchas más posibilidades, es cuestión de
curiosear un poco), en si, la configurarción de estos servidores, consta en que una de las personas cree
un usuario, luego un repositorio (un repositorio no es más que una carpeta en el servidor, pero de ahora
en más, la vamos a llamar respositorio, porque eso es lo que representa, un repositorio de nuestro
código en un servidor), y luego los demás participantes del proyecto también crean sus propios
usuarios, a los cuáles el creador del repositorio irá dándoles permisos (creador significa creador, nada
más, no es el dueño, es simplemente que esta tarea, la debe hacer sólo uno la primera vez).
No olvidemos que lo más importante de la herramienta es que podamos compartir el código,
nadie es propietario del código, ni de niguna parte de él, sino que todos colaboramos en la construcción
de un mismo sistema. El código es de todos.
Una vez que hayamos terminado de crear el repositorio, tenemos que obtener una url (url del
servidor/nombreDelRepositoro) con la cual vamos a interactuar desde el cliente SVN ¿y esto? Esto lo
próximo que vamos a ver. Más adelante vamos a ver bien que tenemos que hacer con esta url, pero en
un rato, por ahora, mantengamos en mente que lo que tenemos hasta ahora, es un servidor de svn, con
un repositorio donde vamos a tener nuestro proyecto versionado y una url, para poder acceder a él.
2 - Instalación del Eclipse y del plugin SVN
Este paso lo pueden cambiar por la IDE que más les guste.
Para poder instalar Eclipse es necesario bajarlo de Internet, se encuentra
http://www.eclipse.org/downloads/, preferentemente la versión para Java EE Developers.
en
Para realizar la instalación se deberá descomprimir el paquete en donde va a quedar instalado.
Si se instalo correctamente la JDK al hacer doble click debería abrir el Eclipse.
Para poder integrar SVN, y Eclipse hay que instalar un plugin para SVN, esto se hace desde el
eclipse: Help -> Install New Software -> y ahí tienen que poner el site del plugin que van a bajar. Está
el botón de Add para agregar uno que no tengan, o bien, ahi abajo tienen un link “Available Software
Sites”, donde pueden buscar el plugin. Luego tienen que seleccionar de la listita que les aparece ahí
abajo lo que se van a bajar, y después el eclipse los va a ir guiando en la instalación del plugin.
Listo, entonces ahora ya tenemos, un repositorio svn donde va a estar nuestro proyecto, y el
cliente svn en el eclipse para que podamos interactuar con él, entonces ya podemos empezar a laburar.
3 - Agregar el repositorio en el eclipse
¿Qué es lo primero que hay que hacer?
Bueno, lo primero sería subir una primera versión del proyecto en el svn.
Pero antes, volvamos al tema repositorio que nos faltan dos cositas más:
Primero en el eclipse vamos a la perspectiva del svn para agregar ahí la url ¿se acuerdan? La url
del repositorio, entonces vamos a Window -> Open Perspective -> SVN Repository Exploring, eso nos
abre la perspectiva de svn (esta perspectiva la tenemos después de que instalamos el plugin de SVN en
el eclipse, si por algun razón la instalación salió mal, entonces no está, tenemos que primero
asegurarnos de tener le plugin bien instalado), ahi, botón derecho, New -> Repository Location, y ahí
pegan la url (les va a pedir el usuario, la contraseña) y listo! Ya tenemos a nuestro cliente SVN en el
eclipse, conectado con nuestro servidor SVN. Es decir, en esta ventana, vamos a ver el proyecto como
está en el servidor SVN (la versión más posta del proyecto). Hasta aca, esto deben hacerlo TODOS los
integrantes del equipo.
Pero ahora el repositorio está vacío, así que ahí (siempre desde nuestra perspectiva del eclipse),
alguno (sólo uno) debe crear 3 carpetas (esta es la segunda cosita que nos falta), la carpeta trunk, tags, y
branches (esto lo estaríamos haciendo directamente sobre el servidor).
Trunk va a ser nuestro proyecto, es decir, lo que nosotros vemos en el eclipse como nuestro
poyecto java, donde adentro van a estar las carpetas src y test, eso mismo va a ser el trunk.
Tags y branches van a ser carpetas donde vamos a guardar otras versiones del mismo proyecto.
Luego vamos a ahondar sobre este tema.
Entonces ahora si:
4 - Subir un proyecto al SVN
Basta con ponerse de acuerdo, y uno de los integrantes del proyecto, crea el proyecto en su
eclipse y lo sube al repositorio, luego todos los demás se lo bajarán en sus máquinas.
Entonces, este paso se hace de la siguiente manera (recuerdan que esto se hace una sola vez, por
una de las personas del equipo): Se crea un proyecto Java en el eclipse, preferentemente con la
siguiente estructura: dos Source Folders, una que se llame src, para las clases del proyecto, y otra que
se llame tests, para poner la clases de tests. Listo, con esto (y/o con cualquier otra cosa que quiera
agregarle) ya puedo subir el proyecto al repositorio, para esto, click derecho sobre el proyecto, Team ->
Share Project, eligen la opción SVN, y ahí tienen dos opciones:

“Create a new repository location” si no la tienen, y ahí pongo la url del repositorio que
debería ser algo parecido a: http://svn.nombreDelServidor.com.ar/tp/trunk por ejemplo.

“Use existing repository location” si ya la tienen y la elijen de la listita (si pasaron por le
paso 3, ya lo deberían tener).
Y ahora me pregunta el nombre que le quiero poner a la carpeta.
Una de las opciones que me propone es “Use project name as folder name”, esto significa que
va a crear en el repositorio una carpeta con el mismo nombre que nuestro proyecto, y ahí va a poner
todos los archivos de nuestro proyecto.
Y la otra opción es “Use specified folder name”.
Por supuesto que hay muchas maneras de subir el proyecto al repositorio por eso existen tantas
opciones, nosotros en la materia vamos a proponer una que es standard, pero sepan que existen
diferentes formas de hacer esto.
Entonces, como nosotros queremos guardar nuestro proyecto en el trunk (más bien, el trunk ES
nuestro proyecto) entonces vamos a elegir la segunda opción, y nosotros le vamos a decir donde lo
tiene que guardar, así que ahí vamos a “Select...” y elegimos la carpeta “trunk”. Y listo, con esto, el
proyecto ya está disponible, en esa dirección. Debería quedar algo así:
Y ahí Finish.
Esto debería llevarnos a otra perspectiva que vamos a usar mucho de ahora en más: Team
Synchronizing. Esta vista lo que nos va a mostrar son los cambio locales que van a subir el servidor, y
viceversa, los cambios del servidor que nosotros deberíamos agregar localmente. Es decir, mediante
esta perspectiva vamos a mantener la comunicación entre nuestro proyecto local y el proyeto que está
en el servidor.
En esta vista deberíamo ver algo como:
Esto significa que, hay cambios “salientes” (es decir, desde nuestro poryecto hacia el servidor,
por eso la flecha para afuera) y el signo “+” significa que estos archivos/carpeta no existen en el
servidor. Vemos que está todo bien, todo esto hay que subirlo al servidor. De vuelta ahora tenemos dos
forma de hacer:
Botón derecho sobre el proyeto -> Commit
O bién, podemor apretar le botoncito que aparece arriba, redondeado en rojo, que hace lo
mismo, “commietamos” (nuevo verbo que agregamos a nuestro vocabulario nerdístico) todos los
cambios locales. Ahí nos aparece una ventana para dejemos un mensaje de lo que estamos subiendo. Es
importante dejar un mensaje de lo que estoy commiteando así cuando quiera buscar algo con el
mensaje lo voy a poder indentificar más rápidamente. Y listo! (por fin...)
Para verificar que lo subí bien, en la perspectiva del SVN debería verse dentro de la carpeta
trunk todas las carpetas y archivos de nuestro proyecto (de la misma manera que se ve dentro del
proyecto java en el eclipse).
5 - Obtención del Proyecto desde el SVN
Bién, hasta acá, ya tenemos: el servidor SVN, el cliente SVN en el eclipse, el repositorio creado
en el servidor, y el proyecto subido al trunk del repositorio, ya casi!!
Ahora, ese alguién que se tomo todo este trabajo, tiene que avisar al resto, que el proyecto ya
está disponible para que todos empiecen a trabajar, en un esquema de código compartido.
¿Y que hacen los demás?
Todos a esta altura deberíamos poder ver el repositorio desde el eclipse (sino, volver al paso 3).
Así que vamos a la perspectiva SVN Repositories Exploring, nos paramos en la carpeta trunk
(importante este paso... SOBRE la carpeta trunk) botón derecho -> Checkout. Y ahí “Check out as a
project in the workspace”, le ponen el nombre que ustedes quieran (total este nombre sólo lo van a ver
ustedes) -> Finish.
Esto les va a crear un proyecto eclipse con el nombre que ustedes eligieron en el paso anterior.
Esta carpeta debería contener lo mismo que contiene la carpeta trunk en el servidor.
¿Entonces que hice acá? Lo que hicimos hasta acá es bajar la última versión que hay del
proyecto en el servidor en ese momento, y el eclipse automáticamente lo reconoce como un proyecto
eclipse y lo agrega en mi repositorio local (lo que más arriba llamamos “working copy”), y acá es
donde voy a trabajar localmente. ¿Localmente? Si, lo próximo que deberíamo ver es como subir todo
mi trabajo local, al servidor.
6 - Commit, Sinchronize y update
Ahora que ya tenemos el proyecto localmente (lo que tenemos es un copia de lo que hay en el
servidor), entonces empezamos a hacerle cambios. Por ejemplo, agregamos un package con algunas
clases, y un package test con una clase de test. Entonces, si vamos a la vista Team Synchronize, vamos
a ver nuestro cambios, los que agregamos. Lo mismo que antes, verificamos que esté todo bien, y le
damos commit. Hasta acá no hay ninguna ciencia.
Ahora, que pasa si mientras nosotros estuvimos programando, hubo alguien que también se bajó
el proyecto a su máquina, hizo sus cambios y “commiteó” antes que nosotros? Lo que pasa es que
nuestro proyecto queda desactualizado, es decir, la última versión del proyecto, es la que está en el
servidor, pero como alguien commiteó, entonces ahora la última versión cambió, y entonces nosotros
ya no estamos trabajando sobre la última versión, sino sobre una anterior. El svn nos exige, que si
nosotros vamos a subir cambios, lo hagamos sobre la última versión, ahora si nosotros hicimos cambios
pero la última versión cambió, entonces, para subir nuestros cambios, primero, debemos estar parados
sobre la última versión, para esto, vamos a la vista Team Synchronize, sobre el proyecto, botón
derecho, Synchronizelo que conocemos como “sincronizar” (otro verbo que agregamos), justamente,
para “sincronizarnos” con el proyecto que está en el servidor.
Y en la vista de cambios entrantes vemos los cambios que están en el servidor, que no tenemos
nostoros
Ahí vemos el archivo que tiene cambios en el servidor, entonces, para bajarlo a nuestro proyecto
local , sobre el proyecto hacemos botón derecho -> update. Esto actualiza nuestra versión del proyecto,
con la que está en el servidor. Ahora que ya estamos parados sobre la última versión del servidor, ya
estamos en condiciones de commitear nuestros cambios.
7 - Solución de conflictos
Ahora, que pasa cuando esa persona justo justo modifió lo mismo que yo, es decir, modificó
algún archivo, en el mismo lugar que yo, por ejemplo, en una clase Persona, donde ya había un atributo
nombre, yo decido agregarle el atributo legajo, pero la otra persona que ya commiteó, le agregó el
atributo domicilio, justo abajo del atributo nombre, en el mismo lugar donde lo puse yo!!
Acá el svn no sabe que hacer, porque tiene un conflicto, cuando quiso actualizar nuestro
proyecto con lo que está en el servidor, se encontró con que yo, en ese lugar tengo otra cosa, entonces
el svn, no pisa los cambio, pero nos avisa que tenemos un conflico, el archivo nos aparece de la
siguiente manera:
El rombito rojo nos indica que en ese archivo, hay un conflico, si le damos doble click al
archivo, el svn, nos va a mostrar donde está el conflico exactamente:
Observemos atentamente este archivo, porque en verdad, nos está dando muchísima
información:
Primero lo que vemos es las dos versiones del archivo, la local, y la que está en el servidor.
Lo que está en rojo, está claro, es donde tuvo el conflicto, donde no supo que hacer, ahí, a mano,
hay que decirle como querría yo que me quede el archivo local. Entonces, copiamos la línea del
servidor, a nuestro archivo, hasta que nos quede así:
Después hay otra marca en negro (que marca un cambio nuestro hacia el servidor) y otra en
azul, marcando lo contrario, un cambio en el servidor, que deberíamos tener nosotros. Al estar en azul,
significa que, el svn ve que hay un cambio en el servidor que nosotros no tenemos localmente, pero que
no tiene un conlicto, con lo que, apretando en el cuadradito que aparece en el medio (redondeado en
rojo) lo pasa a nuestro archivo, y listo, el archivo ya estaría “mergeado” ¿que significa mergeado? Que
ya junte todos los cambios, los mios y los del servidor, entonces, le aviso el eclipse que ya terminé de
hacer el merge, para esto, botón derecho sobre el archivo -> Mark as Merge (este paso es
importantísimo!! Hasta que no haga esto, el svn sigue pensando que estamos en conlicto y no nos va a
dejar commitear. Ahora si, deberían irse todos los rombos colorados, lo que nos deja en la última
versión, y en condiciones de commitear.
Entonces vamos a la viste de cambios saliente:
Y ahora si, botón derecho, commit.
Ahora nosotros subimos al servidor, lo que sería la nueva última versión del proyecto.
Aca, una buena práctica sería avisar al resto del equipo, que hay cambios subidos, para que el
resto actualice su repositorio local.
De todas maneras, SIEMPRE, cuando nos sentamos a trabjar, lo que primero que hacemos, en
un sincronize, y un update, para asegurarnos siempre, de estar trabajando contra la última versión.
Y con esto, ya somos regios usuario del svn.