ocubom's blog

Desde que aprendí mi primer lenguaje de programación (BASIC para SPECTRUM), la forma de programar ha evolucionado de forma radical. De los primeros programas escritos en un editor de líneas en el SPECTRUM, pasando por diversos editores (vim, emacs, notepad, ultraedit…) hasta los más completos IDE como Borland (Turbo y Builder) o Visual Studio.

En los últimos tiempos, sobre todo con el auge de la web, PHP se ha transformado en uno de mis lenguajes más usados. Su potencia ha hecho que no sólo me sirva para implementar páginas web sino pequeños scripts para consola reemplazando a bash o perl.

En los primeros tiempos, los programas en PHP eran muy sencillos y bastaba con cualquier editor. Poco a poco los programas crecían y se hacía más costoso de mantener. La inclusión de frameworks MVC son la gota que colma el vaso haciendo imposible su gestión con un editor sencillo.

Por extraño que parezca PHP carece de un IDE propio que simplifique la programación. Así que tras buscar, escuchar consejos, probar y experimentar llegué a un entorno potente y flexible para programar en PHP, incluso en máquinas remotas.

Leer el resto de esta entrada »

Subversion es un sistema de control de versiones con la política copiar-modificar-mezclar con gran proyección en la actualidad. Por ejemplo, SourceForge (una forja de proyectos libres) utiliza Subversion como control de versiones. Gran parte del éxito de Subversion es su agilidad cuando intervienen varias personas, debido a su política, y a su flexibilidad que no lo limita a desarrollos software: es posible almacenar planos, imágenes, libros…

Pero esta flexibilidad puede volverse en contra del usuario: al crear el repositorio en su interior no existe absolutamente nada y nos encontramos ante el “síndrome de la hoja en blanco”. Para poder extraer el máximo partido a la herramienta es necesario definir una estructura de directorios en la que se almacene la información. Y hay algunas mejores que otras…

Aunque no es obligatorio, prácticamente todos los proyectos de Subversion tienen un primer nivel común. Las políticas aplicadas en este nivel proporcionan coherencia en la gestión y funcionalidades no disponibles de forma nativa. Esta estructura se compone de tres directorios (branches, tags y trunk) y una cuarta opcional (vendor). Es necesario definir cómo funcionan y se usan cada uno de ellos, cómo se gestionan múltiples proyectos… pero cuanto antes se empiece antes se acaba
Leer el resto de esta entrada »

De los múltiples sistemas existentes, uno de los más útiles y utilizados es Subversion. Subversión surge para reemplazar al gestor usado en sistemas Unix (CVS) con el objetivo de mejorar algunos aspectos que dificultaban el uso de la aplicación. Existen versiones tanto del cliente como del servidor para cualquier plataforma.

El servidor de Subversión gestiona un repositorio centralizado con la política copiar-modificar-mezclar. Sin embargo, existen herramientas para sincronizarlo con otros repositorios y es posible configurar repositorios con la política bloquear-modificar-desbloquear. Las características fundamentales son:

• Número de versión global al repositorio que se incrementa con cada cambio, por lo que es posible volver a una versión anterior indicando dicho número global.
• Control de cambios en ficheros y directorios (si, almacena y controla cambios en árboles completos de carpetas y ficheros). Mantiene el histórico de versiones de un fichero aunque se mueva o renombre.
• Detecta y trata apropiadamente los ficheros binarios, uno de los puntos débiles de CVS. A estos ficheros les añade una propiedad indicando su tipo.
• La transmisión entre cliente y servidor incluye únicamente los cambios lo que supone un ahorro del ancho de banda. Además, los cambios se calculan a nivel de byte (en lugar de línea ampliamente usado) lo que reduce aún más el tamaño de las modificaciones.

Por su parte, es posible atacar al servidor utilizando distintos clientes independientemente de la plataforma en la que ejecute cada uno de ellos. Es posible utilizar un cliente en Windows que se conecte con un servidor en Unix o Mac y viceversa. Esta facilidad, permite la creación de clientes bastante avanzados adaptados a cada plataforma como, por ejemplo, la integración con documentos de office que dispone el cliente de Windows.

El uso de subversión es muy sencillo. El proceso si se usa una consola es:

svn co ruta_repositorio [destino]

Descarga una copia (checkout) de cualquier carpeta contenida en el repositorio (no es necesario bajar la raíz del repositorio, se puede bajar cualquier carpeta contenida en el mismo) que se denominará copia de trabajo. La copia de trabajo son ficheros locales en la máquina por lo que puede ser modificada según se desee.

Las rutas de repositorio tienen la forma protocolo://usuario:password@servidor/ruta. Existen múltiples protocolos como Webdav, svn (protocolo propio), svn+ssh (protocolo svn a través de un túnel ssh para asegurarlo…

svn update

Se encarga de descargar los últimos cambios del repositorio y mezclarlos en la copia de trabajo para que coincida con la última versión disponible.

Si en el proceso de mezcla se detectan conflictos irresolubles, se marcan en la copia de trabajo para que el usuario los resuelva. De esta forma, se evita corromper el repositorio.

svn ci [ruta]

Cuando se finalizan los cambios se envían al repositorio (commit). En este momento, se comprueba si la versión base del usuario es la última del repositorio y si es así se envían los cambios creando una nueva revisión.

Si las versiones no coinciden, el usuario deberá actualizar (update) su copia de trabajo con lo que se marcarán los conflictos en la copia de trabajo.

Además de este cliente de consola, existen aplicaciones gráficas que realizan ese trabajo de forma transparente y más agradable para el usuario.

Si se utiliza Windows, la opción más adecuada es TortoiseSVN. Es un cliente que se integra con el explorador de Windows y que permite realizar todas las acciones mediante entradas en el menú contextual de los ficheros y carpetas.

Para el escritorio KDE existe un plugin similar denominado kdesvn aunque no implementa toda su funcionalidad. Sin embargo, para un uso habitual es suficientemente útil.

Cuando se plantea la implantación de mecanismos de gestión de configuración, existen múltiples alternativas que deben ser estudiadas según las necesidades de cada caso.

La primera alternativa, aunque la más desaconsejable, es la gestión manual. En este caso, la línea base es la última versión del producto. Para modificar dicha versión es necesario formular una petición de cambio cumplimentando el formulario definido. Esta petición de cambio es evaluada por un comité para determinar la idoneidad de su implantación y, si es aceptada, se implementa generando una nueva versión. Evidentemente, para evitar que se pierda la versión anterior, es necesario almacenar una copia y es donde surgen los ficheros con nombres según la versión, fechas, ficheros comprimidos con versiones…

Esta alternativa tiene algunos aspectos bastante negativos: su gran sobrecarga, la facilidad con la que el sistema se rompe con lo que es invalidado y la lentitud que supone la burocracia en el proceso de cambio. Su único punto favorable es que es 100% adaptable a las necesidades.

Evidentemente, esta alternativa no es muy viable en la práctica (como sufrí durante ingeniería del software durante la carrera). Sin embargo, existen herramientas que se encargan de automatizar prácticamente todas las tareas: los sistemas de control de versiones.

Los sistemas de control de versiones son programas que se encargan de controlar y gestionar los distintos cambios que se producen en el producto. Este producto puede ser desde el código de un programa, un libro, planos…

Todos los sistemas de control de versiones se basan en el concepto repositorio. Un repositorio no es más que el conjunto de versiones del producto. Una vez creado, los distintos usuarios realizan sus cambios sobre el repositorio que se encarga de almacenarlos permitiendo la recuperación de cualquier versión. Existen dos tipos de repositorios:

Centralizado:

El repositorio es único y reside en una máquina accesible por cualquier usuario. Este es el modelo más usual.

Distribuido:

En este caso, existen múltiples repositorios accesibles por cada usuario. Cada usuario utiliza un repositorio cualquiera y existen mecanismos de sincronización entre repositorios.

En cualquiera de los dos casos, el repositorio es compartido por todos los usuarios (o al mismo usuario desde distintas máquinas) que tengan acceso al mismo. Es posible que se produzcan ediciones simultáneas de los mismos elementos que generen conflictos. Para solucionar este problema existen dos políticas básicas de resolución de conflictos:

bloqueo-modificación-desbloqueo:

En esta política se evitan las modificaciones concurrentes. Cuando un usuario desea realizar una modificación, indica el elemento a modificar que queda bloqueado en el repositorio por lo que se impide el acceso al resto de usuarios (exlusión mutua). Cuando finaliza de realizar sus cambios, los envía al repositorio liberando el bloqueo con lo que el resto de los usuarios puede obtener la copia actualizada para realizar sus propios cambios.

copiar-modificar-mezclar:

Esta política permite las modificaciones simultáneas. Cada usuario hace una copia del repositorio en su máquina y procede trabajar con ella como si no fuera un repositorio. Cuando finaliza su trabajo, envía los cambios al repositorio que se encarga de analizar los cambios realizados por el usuario y los que se han realizado en el propio repositorio y realiza la mezcla.

Evidentemente, la primera política es mucho más restrictiva lo que dificulta el trabajo diario ralentizando el acceso a los recursos y ocasionando problemas si no se liberan recursos bloqueados. La segunda, por su parte, tiene como inconveniente que no siempre es posible mezclar los cambios realizados aunque en esos casos, utiliza al usuario que envía cambios para solucionar esos conflictos irresolubles automáticamente.

Existen numerosas aplicaciones para controlar versiones: CVS, darcs, Sourcesafe, Subversion… cada una con sus características únicas. A partir de la próxima entrega se analizará una de ellas.