PHP5 / Eclipse PDT y Subversion
Una de las interesantes características por las cuales he usado Eclipse PDT en estos días es por su capacidad de conectarse a un recurso SVN para de manera automática gestionar todo el proceso de desarrollo conectado a un sistema de versiones como Subversion.
En el caso de PHP5, Eclipse PDT puede usar (al igual que cualquier suite basada en eclipse) subclipse; subclipse es un plugin para Eclipse que permite gestionar todo el proceso básico de trabajo con un sistema de versiones (add, update, commit, diff, merge son realizados casi sin ningún problema).
Como instalarlo
Para instalarlo tenemos que ir al menú Help -> Software Updates -> Find and Install …
En la ventana que aparece debemos indicar que vamos a instalar nuevas características (”Search for new features to install” y Next >)
En la ventana de componentes, indicamos que deseamos agregar un nuevo remote site …
El Plugin que vamos a agregar es el siguiente:
Name: Subclipse 1.2.x (Eclipse 3.2+)
URL: http://subclipse.tigris.org/update_1.2.x
Siguiendo los pasos de “next, next, next, finish” (:D ¡Que dificil es Linux!) tendremos nuestro plugin funcionando correctamente.
Nuestros primeros “pinitos” con Subclipse
Aun cuando subclipe tiene la posibilidad de hacer Checkout y agregarlo como un proyecto nuevo en nuestro arbol de proyectos; realmente preferí hacerlo de la manera tradicional; en mi caso:
Una consola:
>svn co http://svn.covetel.com.ve/tomates/trunk/ tomates/
*he descargado de mi sitio web una copia del fuente de Tomates Framework.
Me ha creado una carpeta donde yo me encontraba (en este caso, /var/www/tomates/) y puedo usar ahora esa carpeta como proyecto de Eclipse.
Creando un proyecto de Eclipse PDT
En la perspectiva PHP (menú Window -> Open Perspective -> PHP) indicar File -> new -> PHP Project
Llenar la ventana siguiente con los datos del proyecto (ruta, nombre, si es PHP5 especificamente, etc)
Luego de llenados los datos, presionen Finish y se creará un árbol de proyecto como el siguiente:
Ahora solamente basta con sincronizar dicho proyecto con un repositorio existente:
En la perspectiva SVN Repository ejecutamos botón derecho > New > Repository Location … En la ventana (para qué screenshot?, si tiene un único cuadro de texto!) agregamos el URL del repositorio SVN, Finish! y este es cargado como un repositorio de trabajo.
La otra forma consiste en Botón derecho sobre el proyecto > Team > Share Project e indicar “New repository” en la opción de “cual repositorio se usará” para el proyecto actual.
El Menú Team
El menú Team se actualiza una vez que nuestro proyecto está asociado a un repositorio SVN; este muestra las distintas tareas que se pueden realizar con nuestro proyecto y su sincronización con el repositorio:
La primera opción nos permite sincronizarnos con el repositorio para comenzar a trabajar (esta opción llena la perspectiva “Team Synchronizing Perspective” y es una perspectiva que me permite gestionar el estado de mi repositorio (mensajes de error, SVN annotates, estado de los conflictos de código, anteriormente tareas bastante engorrosas de hacer por consola y hacerlas con rapidSVN era como estar desligado del proceso mismo de desarrollo).
Comandos SVN: Su equivalencia con el Menú Team
svn update -> Update: permite mantenernos actualizados con el código que terceros de nuestro proyecto han realizado.
svn commit -> Commit … permite agregar nuestros cambios al repositorio ; de manera interesante, Commit … gestiona automáticamente todo archivo nuevo que agreguemos y todo archivo que borremos, de manera que Commit … es una fusión de los comandos svn add y svn delete.
svn merge -> Merge … muchas veces tenemos código escrito por distintos programadores en distintas partes de un mismo archivo, svn merge permite fusionar el código de sectores diferentes
svn diff -> create patch … Si un archivo contiene diferencias a la versión que se encuentra en el repositorio y deseamos crear un patch (archivo de cambios), hacemos click sobre el archivo en conflicto y ejecutamos Team -> create patch …
Enviando nuestros cambios al servidor
Si somos muy activos escribiendo código entonces commit … es una de las ventanas que más usaremos; commit puede actuar sobre el proyecto entero (haciendo click sobre el proyecto, botón derecho > Team > commit …) con lo cual se agregarán todos los cambios globales realizados, o a nivel de un archivo único o carpeta (haciendo click en el archivo o carpeta específicos, puedo realizar botón derecho > Team > Commit … y solo se enviarán los cambios en dicho archivo).
Fijense en la ventana anterior; además de la posibilidad de un comentario (svn commit -m ‘comentario’ como se hace en consola), fijense que commit … ha detectado que he borrado un archivo y he agregado una carpeta (aparecen como deleted y unversioned) además de el archivo modificado (que aparece marcado como modified); las carpetas .settings y .project son del Eclipse así que eso no lo envio al repositorio (aunque debería ocultarlo o algo así).
Pero me equivoqué!
Revertir cambios no deseados para no contaminar el repositorio es tan sencillo como detenerse en el archivo (o carpeta, en caso de ser muchos) y ejecutar Team > revert y los cambios serán regresados a la última revisión del repositorio sin causar conflicto entre archivo local y remoto.
Resolviendo diferencias
Otra de las cosas interesantes de Subclipse es la posibilidad de revisar en “Team Synchronizing Perspective” la posibilidad de que existan archivos con diferencias entre la versión local y la versión en el repositorio; para esto:
Al abrir un archivo en la perspectiva “Team Synchronization” veremos nuestro archivo local a la izquiera y el remoto a la derecha; las diferencias vendrán marcadas por una linea negra rodeando el sector de código diferente y un cuadro negro por cada diferencia en la scrollbar; con los botones de arriba podemos copiar el código de un lado a otro del archivo o resolver las diferencias no-conflictivas (para las conflictivas tendremos que editar nuestro código :p).
Para cuando hemos terminado de resolver los conflictos, podemos ejecutar botón derecho sobre el archivo “Mark as Resolved” o en caso de haber realizado un Merge de código “Mark as Merged” y posteriormente Commit … para así guardar los cambios en nuestro repositorio.
La estabilidad, creando branches
Si el proyecto es muy activo (o está en fases iniciales) y llegamos a un punto donde declaramos una cierta “estabilidad” al código, pero queremos seguir agregando cambios (sin afectar que los usuarios finales puedan descargar el código para su uso o prueba) decretamos la creación de una branch (rama) que no es más que la declaración de un release de nuestro código en el repositorio; es tan facil como hacer click en nuestro proyecto y ejecutar botón derecho > Team > Branches/Tags y definir hacia donde va el código de la nueva rama (en el caso de tomates, http://svn.covetel.com.ve/tomates/branches/).
Ver lo que los demás han hecho y comentado
Por lo general los comentarios de cada revisión y las anotaciones en la rama SVN ayudan de mucho a saber que están haciendo los programadores y a continuar el trabajo sin pasar media hora dando vueltas a ver que cosas nuevas agregaron; Team > view comments y Team > View History me permite ver las anotaciones y la historia de las revisiones del repositorio actual.
Conclusiones
Para un usuario de GUI e IDE’s esto es una caraterística más que nos mantiene acostumbrados al uso de herramientas de desarrollo fáciles y rápidas, es de agradecer las capacidades de mantener a mi equipo de desarrollo sincronizados con los cambios sin tener que estar ejecutando comandos por consola o preocupandose por algo más que contribuir con código al proyecto; también es de hacer notar que si un abyecto y abnegado usuario de vim (muy potente editor por cierto) como walter (alias elsanto) ha dejado de usar vim para programar para unirse a los usuarios de Eclipse (en su caso como le gusta javascript/jquery usa aptana IDE) y de verdad comenzar a trabajar de manera colaborativa y sin estar ejecutando comandos raros en la consola.
Leave a Reply