Control de versión (o como trabajar de manera organizada)

Los proyectos en los que intervienen muchas personas de distintas áreas requieren gran organización (para saber quien está haciendo, hizo o hará que cosa) y métodos eficientes de integración de partes (para poder poner a funcionar de manera rápida lo que hace un diseñador, un programador, un arquitecto y un documentador).

Al ser muchos los participantes, muchas veces sucede que un mismo archivo requiere ser modificado por varias personas a la vez; peor aún, suele suceder que el cambio que un participante introduce sobre un archivo o módulo provoque muchos problemas en otros módulos y requiera intervención para solucionarlos. ¿cómo hacen los grandes proyectos de software, especialmente los que se encuentran distribuídos en muchos países y de los que participan miles de programadores, para mantenerse organizados, evitar desastres y salir adelante? Simple, utilizan herramientas para control de versiones que se encargan de mantener un histórico de cada cambio introducido sobre cada parte, y que permite no solo revisarlos sino también volver atrás en caso de ser necesario.

Existen muchas herramientas de este tipo, desde el viejo y conocido CVS, el tan popular SVN o incluso el flamante bazaar, con su arquitectura distribuída de la que tanto hablan. Pero, básicamente, todos hacen lo mismo: controlan los cambios sobre las distintas partes del proyecto, y facilitan de este modo la integración en un mismo “branch” de todo lo que cada participante fue haciendo, agregando, modificando o eliminando.

Aquí les voy a hablar de SVN, simplemente porque es el que más conozco y porque es uno de los más difundidos del mundo. CVS está tendiendo a desaparecer, y existen nuevos softwares (como Bazaar) que están emergiendo y que prometen cambios muy interesantes. Arranquemos…

Primero vamos a dar un vistazo general a la organización de un proyecto en SVN. Tenemos por un lado un repositorio, donde están todos los archivos (y todas sus versiones) de un proyecto en particular. Ese repositorio se puede acceder mediante un cliente svn por medio de una url del tipo: svn://repositorio.com.ar . Por el otro lado, tenemos los clientes SVN (ya hablamos bastante de clientes y servidores, si alguien necesitan un repaso puede revisar aquí ), quienes se encargan de comunicarse con el repositorio SVN y sincronizarse mutuamente. Y ahora viene lo bueno…

Un cliente SVN puede realizar principalmente dos grandes acciones: commit y update. Existen otras acciones, como por ejemplo checkout, que se utiliza la primera vez que se entra a un proyecto y sirve para obtener una copia de todos los archivos del proyecto; el punto es que la mayoría de las acciones sirven para casos específicos, y son raramente usadas. Analicemos un poco estas dos:

  • update:  Cuando un cliente SVN le indica a un repositorio que quiere hacer un update sobre un determinado proyecto (tengamos en cuenta que un mismo repositorio puede tener varios proyectos, y que un mismo cliente puede participar en varios de ellos), el servidor se fija de algún modo que versión de cada archivo posee este cliente, y le envía sólo aquellos que han cambiado. Esto quiere decir que, si el proyecto tiene mil millones de archivos, pero desde la última vez que hice un update solo han cambiado 5, pues recibiré solo los cambios sobre esos 5 archivos y no todo el proyecto nuevamente. Al realizar un update, cada archivo puede ser actualizado de diferentes maneras, y el cliente SVN nos indicará que ha sucedido con cada uno. Los cambios pueden ser:
  • A (ADDED) Se ha incorporado un nuevo archivo, que nosotros no teníamos. No pasa nada, simplemente se agrega al proyecto
    • D (DELETED) Se ha eliminado un archivo, esto podría generar inconvenientes y hay que prestar atención
    • G (MERGED) Un archivo ha sido modificado. Nuestro cliente fue capaz de detectar estos cambios y cominarlos con nuestra version; de este modo, nos evita tener que revisar que ha cambiado cada uno, ya que lo hace de manera automática.
    • C (CONFLICTED) Un archivo ha cambiado, pero por algún motivo el cliente no ha podido introducir los cambios, ya que llevaría a un conflicto. En este caso, se requiere intervención humana, que decidirá que hacer. Afortunadamente, el cliente coloca unas marcas sobre el archivo indicando que era lo que teníamos notroso (MINE) y que introduce esta nueva revisión. Por lo general, resolver conflictos es una cuestión de segundos.
  • commit: Esta segunda acción es la que nos permite enviar al repositorio todos nuestros cambios. Es muy importante que nuestro proyecto este actualizado (hayamos hecho un update) antes de hacer el commit, ya que de lo contrario nos arrojará un error.

Metodología de trabajo.

Ya vimos la parte teórica del SVN, ahora veamos la parte práctica. ¿cómo integro todo esto en mi proyecto, siendo yo un desarrollador más?

La idea es que cada desarrollador trabaje en su propia PC, y que no dependa de servidores de terceros en el caso de proyectos web (php, java, perl, ruby, etc). De este modo, se evita tener que subir archivos mediante ftp, samba, ssh o lo que fuere a un servidor centralizado para poder probar las cosas. Hace no mucho les expliqué como armarse su propio servidor web, y la idea es que trabajen con su propio servidor de manera totalmente local. De este modo, es muchísimo más fácil introducir cambios y probarlos inmediatamente. Incluso, de puede trabajar si conexión a internet, ya que siempre lo hacemos de manera totalmente local.

1. El primer paso será, como les comenté, hacer un checkout del proyecto, para poder recibir todos los archivos. El checkout lo hacemos sobre una carpeta o directorio del sistema (idealmente, si tenemos un servidor web, hacemos el checkout dentro del directorio que representa nuestro árbol web😀 y listo, no tenemos que andar moviendo archivos de un lugar a otro).

2. Ahora, trabajamos como si nada, con archivos locales. Agregamos, modificamos o eliminamos archivos.

3. Cuando consideramos que nuestros cambios están lo suficientemente estables, hacemos un commit para que todos los participantes del proyecto puedan tener la versión con nuestros cambios incorporados. Recuerden que antes de hacer un commit, se recomienda hacer un update.

Es una buena costumbre hacer un update cada día, antes de comenzar a trabajar en el proyecto. De este modo, estaremos trabajando siempre sobre la última versión del proyecto.

Un poco de seguridad.

De más está la aclaración, pero la hago igual. No cualquier persona puede involucrarse en cualquier proyecto. Existe un administrador, quien le da un usuario y una clave a cada participante; cada uno de ellos deberá utilizar estos datos cada vez que quiera hacer un checkout, commit o update. Sino, sería un caos total.

Es importante que quede en claro que todos los archivos que se encuentran dentro del directorio del proyecto serán enviados (salvo que se indique explícitamente que no) al repositorio. Esto quiere decir que, si yo soy un diseñador web y estoy trabajando con imágenes vectoriales de 100 mb que luego exportaré a un jpg para colocar en la página web, no debería tener estas imágenes tan grandes dentro del proyecto. Las trabajo por fuera, y cuando las exporto lo hago dentro del proyecto. De este modo, ni tengo que subir archivo gigantes, y hago que el resto de las personas tengan que descargarse cientos de megabytes.

Herramientas.

El cliente SVN más famoso es el Tortoise SVN, el cual se integra perfectamente al escritorio Windows. Las acciones que les expliqué mas arriba las muestra en el menú contextual de cada carpeta, con lo cual hacer un update o un commit es muy facil.

En Linux, Unix, Solaris y Mac, tienen la misma herramienta, , pero las instrucciones de instalación varían de versión en versión (en debian y ubuntu, es tan facil como apt-get install subversion). Más información aquí.

El desarrollador de Tortoise SVN, Tigris, también ha creado versiones de su cliente SVN que se integran perfectamente con  los IDEs de desarrollo más populares: Eclipse, NetBeans, JDeveloper, Visual Studio. Si bien pueden obtener más información en http://www.tigris.org, yo les recomiendo que busquen por ahí como instalarlo para cada IDE (en eclipse, por ejemplo, es muy facil si se sigue el tutorial en linea).

2 comentarios to “Control de versión (o como trabajar de manera organizada)”

  1. Gastón Says:

    Gracias, leí como 100 millones de explicaciones y está ha terminado de hacerme entender como funciona.

    Gracias🙂.

  2. Como borrar los .SVN de manera sencilla | Paraiso Linux Says:

    […] saben lo que son los .svn? Ni siquiera saben lo que es SVN?! Pues yo no se los voy a explicar, pero en esta web esta super clarito. Resumidamente SVN un sistema de versionado para llevar control de los cambios […]


Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: