Cómo: Usar Eclipse IDE con Subversion para desarrollo PHP con control de versiones

He usado Zend Develpment Environment desde hace unos 5 años para el desarrollo de software, las nuevas versiones se volvieron cada vez más (demasiado?) sofisticadas para mi gusto y empezaron a volverse muy restrictivas en cuanto al licenciamiento de uso, así como a implementar/requerir diferentes plataformas/versiones de algo que debería ser simple y sencillo y que ellos lo empezaron a complicar con servers, debuggers, plattforms y más y más cosas.

Por otro lado los costos son cada vez menos accesibles, pues ya no puedes tomar sólo el IDE, ahora necesitas todo un pack que trae un pequeño arsenal de “esas cosas” que describí y que honestamente no necesito.

Con dos minutos de investigación en Internet cualquiera puede determinar que, al menos para mis necesidades, el indicado debería ser Eclipse. Analicé también NetBeans, pero honestamente Eclipse está mejor parado en cuanto a desarrollo PHP. Sí, NetBeans puede ser un poco más intuitivo de usar, pero luego de “tontearle” un poco, Eclipse se vuelve bastante versátil. Adicionalmente, el crecimiento de uso de Eclipse en plataformas Linux ha sido algunas veces más grande que el de NetBeans.

Entrando ya en materia, en mi Fedora 14 he instalado Eclipse IDE de la manera habitual:

yum -y install eclipse eclipse-phpeclipse eclipse-subclipse

Nótese que he agregado el plugin de soporte para desarrollo PHP (phpeclipse) así como el de Subversion (subclipse) para control de versiones pues el sistema que Eclipse trae por defecto es CVS. Al momento la versión más nueva estable y la que instalé es la 3.6 (Helios).

Una vez instalado sólo hay que abrirlo:

Creamos un nuevo proyecto con: Archivo -> Nuevo -> PHP Project. Asegúrate de seleccionar PHP Project dentro de el ítem PHP:

En el siguiente paso debes indicar el nombre para tu proyecto y si deseas le cambias la ubicación predeterminada (yo la dejé tal cual):

Listo, ya tienes un proyecto nuevo y en blanco para empezar tu trabajo. A partir de aquí podrías simplemente agregar archivos al proyecto con un clic derecho sobre el nombre del mismo a la izquierda y poner el código necesario dentro!

Pero si quieres hacerlo un poco más serio y deseas agregarle control de versiones, hay que realizar unos pocos pasos más.

Nota: Se asume que para el control de versiones tú ya has creado un repositorio de archivos SVN para el proyecto. Antes ya escribí un post sobre el uso de Subversion para el control de versiones donde describo cómo hacerlo.

En Eclipse existen las denomidas perspectivas. Para ponerlo de una manera sencilla, el concepto de “perspectivas” en Eclipse no es más que una organización de las diferentes ventanas en el espacio de trabajo. Entonces comencemos con agregar la perspectiva de Subversion en nuestro espacio de trabajo haciendo clic sobre el ícono de Abrir perspectiva arriba a la derecha del espacio de trabajo:

Y seleccionamos SVN Repository Exploring de la lista y clic en Aceptar:

Con lo cual obtenemos ya la perspectiva de exploración de repositorio SVN, donde haremos clic sobre el botón de Add SVN Repository resaltado en la imagen, para añadir nuestro repositorio SVN:

Ingresamos la URL del repositorio:

Si el repositorio tiene contraseña te la solicitará para desplegar el contenido del mismo en la ventana de árbol de la izquierda. Una vez enganchado al repositorio podrás explorarlo normalmente:

Ahora hay que enlazar el repositorio con el proyecto, para lo cual hacemos clic derecho sobre el repositorio y seleccionamos Checkout... con lo cual obtendremos el formulario de opciones:

Observa que yo seleccioné la opción Check out as a project in the workspace con lo cual haré la importación de los archivos hacia el proyecto que creé anteriormente (lo sobre escribiré en realidad). Para ello coloqué además el mismo nombre de proyecto y luego clic en Siguiente.

Sólo queda la ventana de confirmación de que haremos checkout sobre el espacio de trabajo por defecto. Clic en Finalizar:

Me advierte que estoy haciendo checkout sobre el raíz del repositorio, lo cual es correcto en mi caso pues así es como organicé mi repositorio:

Nos solicita confirmación para sobre escribir el proyecto que habíamos creado originalmente, lo cual como dije antes es OK. Sin embargo pudieron obviar la parte de crear el directorio e ir directo a generarlo desde la opción de checkout de SVN, pero preferí indicar también cómo crear un proyecto por si no se deseara seguir con SVN quizá por ser un proyecto muy simple o por cualquier otra razón.

Dependiendo del tamaño y cantidad de archivos dentro del repositorio, el proceso de checkout tomará más o menos tiempo:

Una vez terminado el proceso de checkout podremos regresar a la perspectiva PHP y veremos que el proyecto ha sido cargado con todos los archivos descargados desde el repositorio:

Nótese que los archivos tienen un pequeñísimo cilindro color naranja en la esquina inferior derecha del ícono, lo cual indica que están siendo “versionados”, con SVN en nuestro caso. El cilindro naranja cambia por un + si el archivo es nuevo, un * si tiene modificaciones, etc. Todos ellos indican que hay variaciones locales respecto a la última revisión descargada del repositorio. La tarea más común en este caso será la de Commit los cambios hacia el repositorio, para lo cual hacemos clic derecho sobre el proyecto para aplicar todos los cambios sobre el repositorio (nueva revisión) o sobre un archivo o carpeta para aplicar los cambios particulares de ese archivo o carpeta, que igualmente genera una nueva revisión en el repositorio; luego seleccionamos Trabajo en equipo y Commit... a lo que nos abre una ventana donde deberemos agregar un comentario que será incluido en el log de la nueva revisión y adicionalmente (abajo) me permite revisar los archivos que serán aplicados al repositorio en esta nueva revisión:

En el mismo menú de Trabajo en equipo están disponibles las demás opciones de trabajo con control de versiones, como Update, Diff, Patch, Merge, Log, etc., muchas de ellas quizá con nombres diferentes pero que hacen lo mismo que las descritas. Sólo es cuestión de poner manos a la obra e ir moneando y aprendiendo… Aún tengo pegadas algunas de las mañas adquiridas de tanto usar ZDE pero he encontrado al menos 3 o 4 características muy interesantes en Eclipse que ZDE no tenía y que aprecio mucho.

5 comentarios:

  1. Muy buen artículo muchas gracias por la información!

  2. Hola Isaías. Cada vez que realizas cambios en la copia local de tu proyecto, podrás poner estos cambios en el repositorio. Esto no se hace cada vez que grabas un cambio localmente, deberás necesariamente escoger la opción Commit en el menú de Trabajo en Equipo (esto se explica en el artículo original). Cada vez que hagas un Commit, se graba una nueva revisión. Una revisión es algo así como una versión dentro del desarrollo del proyecto y se identifican con un número entero consecutivo, el primer commit es la revisión 1, el segundo commit es la revisión 2 y así sucesivamente. El SVN por defecto trabaja sobre la última versión o revisión. Si por alguna razón deseas regresar a una versión anterior, basta conque hagas un Update (en el mismo menú de Trabajo en equipo) y especifiques la revisión a la que quieres ir. De esta manera el sistema hará todo lo necesario para ponerte los archivos exactamente como estaban en esa revisión. Si de este punto luego quisieras ir a cualquier otra revisión anterior o futura, el proceso sería el mismo. Recuerda que el comando Update sin un número de revisión te coloca en la última revisión del proyecto.

    De esta manera puedes tener siempre acceso a cualquiera de los estados registrados (revisiones) del proyecto en cualquier momento. Adicionalmente podras obtener lo que se conoce como archivos diff que son archivos que contienen las diferencias entre una versión y otra. En realidad estos archivos tienen una sintaxis un poco críptica porque sirven para manejar lo que se llaman Patches o parches que son paquetes de diffs que lo que hacen es aplicar los cambios realizados entre una versión y otra, normalmente para aplicar actualizaciones sin reinstalar o recompilar el software original. En realidad este es un tema del que debería escribir un artículo separado 😉

    En fin, espero haber sido de ayuda en tu pregunta!

  3. Hola yo tengo una duda que espero me puedas aclarar cuando mi proyecto ya esta en el repositorio como puedo trabajarlo, para ir guardando las diferentes versiones, digo sin modificar las anteriores

  4. Hola Andrea,

    Qué gusto que te haya podido ayudar!

  5. Excelente articulo. Me ha sido de mucha ayuda. Gracias!

No se admiten más comentarios