Subversion es una herramienta de control de revisiones muy popular, desarrollada para reemplazar a CVS, con el objetivo de mejorar algunos aspectos que dificultaban el uso de la aplicación. Tiene una arquitectura centralizada tipo cliente/servidor
Subversion es una herramienta de control de revisiones muy popular, desarrollada para reemplazar a CVS, con el objetivo de mejorar algunos aspectos que dificultaban el uso de la aplicación. Tiene una arquitectura centralizada tipo cliente/servidor
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.
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.
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, también se puede integrar Subversion a distintas plataformas de desarrollo que funcionan como clientes como netbeans, eclipse, Dreamweaver.
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. Igualmente las plataformas mencionadas anteriormente igual son clientes gráficos que permiten esta integración.
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.
Mostrando entradas con la etiqueta Centralizado. Mostrar todas las entradas
Mostrando entradas con la etiqueta Centralizado. Mostrar todas las entradas
jueves, 10 de diciembre de 2009
Concurrent Versions System (CVS)
El Sistema de Control de Versiones más conocido por sus siglas en inglés CVS (Concurrent Versions System) es una herramienta que mantiene el registro de todo el trabajo y los cambios en la implementación de un proyecto informático (de software) y permite que distintos desarrolladores (potencialmente situados a gran distancia) colaboren en el mismo.
CVS es una herramienta que funciona en un esquema de cliente y servidor. Existe un cliente o estación de trabajo en donde los desarrolladores hacen modificaciones al código y realizan las pruebas necesarias para satisfacer los requerimientos. En el servidor existe una versión consolidada del proyecto. Cada cierto tiempo los desarrolladores actualizan sus versiones de trabajo desde el servidor y por otra parte envían sus propios cambios hacia el servidor.
Existen servidores para Linux y Unix, así como clientes para una extensa gama de plataformas (Linux, Windows, Mac OS, etc).
Uno de los beneficios de este esquema, es que se puede integrar la funcionalidad de cliente CVS en las herramientas de desarrollo integradas. En la plataforma Linux es común que se realice esta integración, debido a lo fundamental que se ha convertido CVS en la mayoría de los proyectos que integran estas plataformas. Es así como por ejemplo podemos encontrar KDevelop de KDE, Anjuta y Eclipse en GNOME, Windows integrados con CVS.
CVS como herramienta no resuelve todos los problemas del desarrollo en equipo.
Simplemente es una ayuda para que las cosas más tediosas puedan ser automatizadas.
Las aéreas en donde CVS no está involucrado tienen relación con el tratamiento del proyecto a un nivel global. Actividades como la planificación, los releases, etc, quedan fuera de su ámbito de trabajo y deben ser abordadas por las personas y otras herramientas complementarias
CVS es una herramienta que funciona en un esquema de cliente y servidor. Existe un cliente o estación de trabajo en donde los desarrolladores hacen modificaciones al código y realizan las pruebas necesarias para satisfacer los requerimientos. En el servidor existe una versión consolidada del proyecto. Cada cierto tiempo los desarrolladores actualizan sus versiones de trabajo desde el servidor y por otra parte envían sus propios cambios hacia el servidor.
Existen servidores para Linux y Unix, así como clientes para una extensa gama de plataformas (Linux, Windows, Mac OS, etc).
Uno de los beneficios de este esquema, es que se puede integrar la funcionalidad de cliente CVS en las herramientas de desarrollo integradas. En la plataforma Linux es común que se realice esta integración, debido a lo fundamental que se ha convertido CVS en la mayoría de los proyectos que integran estas plataformas. Es así como por ejemplo podemos encontrar KDevelop de KDE, Anjuta y Eclipse en GNOME, Windows integrados con CVS.
CVS como herramienta no resuelve todos los problemas del desarrollo en equipo.
Simplemente es una ayuda para que las cosas más tediosas puedan ser automatizadas.
Las aéreas en donde CVS no está involucrado tienen relación con el tratamiento del proyecto a un nivel global. Actividades como la planificación, los releases, etc, quedan fuera de su ámbito de trabajo y deben ser abordadas por las personas y otras herramientas complementarias
Control de Versiones
Durante el desarrollo de cualquier producto, no solamente del código de un programa, éste evoluciona mientras se realizan sucesivos cambios en él. Sin ir más lejos, un libro no se escribe entero en un par de horas sino que se prolonga durante un número de sesiones indeterminadas durante las cuales se añade más y más contenido. Esta adición de contenido realmente son cambios sucesivos al documento. Evidentemente, no todos los cambios consisten en adicciones sino que muchas veces se modifican o eliminan partes ya existentes por diversos motivos.
Generalmente cuando se están desarrollando proyectos ya sean pequeños o grandes se tiene como mínimo la participación de dos desarrolladores, esto hace que se trabaje en diferentes módulos del proyecto que luego de manera manual serán pegadas las partes, sin embargo si el grupo de desarrolladores va creciendo el modo de pegar las partes creadas por cada programador se vuelve bien difícil y complicada, es por eso que a lo largo de los años se han desarrollado diferentes herramientas que permiten llevar un control de las distintas versiones de los proyectos, donde se permite gestionar de una manera más organizada los repositorios de archivos y sus distintas versiones, utilizando una arquitectura cliente-servidor, donde un servidor guarda las versiones actuales del proyecto y su historia, todo esto dependiendo de las cambios y actualizaciones que haga el desarrollador. Independientemente del tipo de cambio realizado, los cambios no son siempre definitivos ni correctos. En muchos casos, un cambio introduce un error que es corregido con cambios posteriores pero, en algunos casos, se desearía poder deshacer completamente un cambio erróneo. En estas circunstancias es cuando interviene los programas de gestión de versiones.
Mediante los procesos definidos de estos sistemas, es posible trazar los cambios que se han realizado en el tiempo. Al disponer de esta información, es posible identificar y controlar todos y cada uno de los cambios realizados. Asimismo, es posible regenerar sin errores el estado del producto en cualquier momento de su desarrollo, es decir, cualquiera de sus versiones, además nos da una serie de ventajas, ya que permite que varios clientes pueden sacar copias del proyecto al mismo tiempo, realizar cambios a los ficheros manteniendo un histórico de los cambios, deshacer los cambios hechos en un momento dado y recuperar versiones pasadas así evitando posibles errores que ocurran en un proceso de actualización, también permiten ver un histórico de cambios y comentarios, lo cual permite que los clientes pueden también comparar diferentes versiones de archivos.
Llevar este control puede parecer complejo en un inicio pero simplifica enormemente el trabajo a corto plazo. Una vez implantado se transforma en una herramienta indispensable de trabajo.
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
Cuando se desarrollaron los sistemas de control de versiones, muchos de ellos se hicieron en esquema cliente-servidor, con lo que el desarrollo de las herramientas está claramente diferenciado entre:
•El cliente: Es la aplicación que se conecta al servidor y mantiene una copia local del repositorio, así como se encarga, generalmente de la corrección de conflictos y la mayoría de lógica del sistema.
•El servidor: Es el sistema que toma los datos del cliente y los almacena a espera de una o múltiples peticiones de esos datos. Este sistema se encargaría del almacenamiento de las versiones, control de concurrencia, bloqueos y otras características parecidas a las de las bases de datos.
¿Qué limitaciones y características posee?
•El sistema servidor es un repositorio, como los que mantienen los clientes, pero perfectamente sincronizado y sin que dé lugar a conflictos. Es la copia maestra de los datos.
•Cuando un sistema web quiere hacer un listado, puede tomar los datos de este servidor y siempre serán seguros, con lo que no tendrá que resolver conflictos, ni tendrá que hacer mezclas.
•Una copia local debe de poder mezclarse con el repositorio central cuando queramos publicar un conjunto de cambios o cuando queramos tomar la última versión publicada en concordancia con nuestra copia local.
•Es normal ver en muchos de estos sistemas ramificaciones, versiones, etiquetas, o similares, a modo de tener varias copias según nos interese. Estas ramificaciones están en el servidor y en algunos casos puede llegar a ser muy costosa su diferenciación.
Algunos ejemplos de Controladores de Versiones Centralizados:
•Concurrent Versions System (CVS)
•SubVersion
Distribuido
Desarrolladores como Linus Torvalds, Eric S. Raymond y otros más, han desarrollado sistemas distribuidos de control de versiones tales como GIT, Baazaar, Mercurial, darcs, entre otros; estos sistemas se destacan por haber sido desarrollados en un formato distribuido, esto quiere decir que, en sí, no hay un servidor que mantenga una copia del repositorio, sino que está mantenida entre los clientes que estén en uso del repositorio y, al igual que los clientes P2P, mientras más desarrolladores haya conectados, mejor conectividad habrá entre todos.
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 (exclusió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.
Esto da una serie de ventajas al sistema centralizado, como son:
•Disponer de forma distribuida de la información del repositorio al completo, tanto de forma local, como a través de los demás componentes del grupo.
•Cada cambio se va replicando entre los demás equipos distribuidos, a modo de que puedan emplear esos datos y actualizarlos en sus sistemas.
•El sistema de control de versiones distribuido ha sido pensado con la forma de trabajo basada en ramas, unión central en una sola versión (trunk) y liberaciones (o tags). Con lo que cada rama puede identificarse como cada copia distribuida que se use.
•Una máquina servidora puede emplearse, al estar siempre conectada, como otro punto de sincronización, con la ventaja de que, aunque cayera, mientras haya más miembros conectados, el sistema siempre se mantiene activo y con buen ancho de banda.
Algunos ejemplos de Controladores de Versiones Distribuidos:
•Baazaar
•Mercurial
•GIT
Generalmente cuando se están desarrollando proyectos ya sean pequeños o grandes se tiene como mínimo la participación de dos desarrolladores, esto hace que se trabaje en diferentes módulos del proyecto que luego de manera manual serán pegadas las partes, sin embargo si el grupo de desarrolladores va creciendo el modo de pegar las partes creadas por cada programador se vuelve bien difícil y complicada, es por eso que a lo largo de los años se han desarrollado diferentes herramientas que permiten llevar un control de las distintas versiones de los proyectos, donde se permite gestionar de una manera más organizada los repositorios de archivos y sus distintas versiones, utilizando una arquitectura cliente-servidor, donde un servidor guarda las versiones actuales del proyecto y su historia, todo esto dependiendo de las cambios y actualizaciones que haga el desarrollador. Independientemente del tipo de cambio realizado, los cambios no son siempre definitivos ni correctos. En muchos casos, un cambio introduce un error que es corregido con cambios posteriores pero, en algunos casos, se desearía poder deshacer completamente un cambio erróneo. En estas circunstancias es cuando interviene los programas de gestión de versiones.
Mediante los procesos definidos de estos sistemas, es posible trazar los cambios que se han realizado en el tiempo. Al disponer de esta información, es posible identificar y controlar todos y cada uno de los cambios realizados. Asimismo, es posible regenerar sin errores el estado del producto en cualquier momento de su desarrollo, es decir, cualquiera de sus versiones, además nos da una serie de ventajas, ya que permite que varios clientes pueden sacar copias del proyecto al mismo tiempo, realizar cambios a los ficheros manteniendo un histórico de los cambios, deshacer los cambios hechos en un momento dado y recuperar versiones pasadas así evitando posibles errores que ocurran en un proceso de actualización, también permiten ver un histórico de cambios y comentarios, lo cual permite que los clientes pueden también comparar diferentes versiones de archivos.
Llevar este control puede parecer complejo en un inicio pero simplifica enormemente el trabajo a corto plazo. Una vez implantado se transforma en una herramienta indispensable de trabajo.
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
Cuando se desarrollaron los sistemas de control de versiones, muchos de ellos se hicieron en esquema cliente-servidor, con lo que el desarrollo de las herramientas está claramente diferenciado entre:
•El cliente: Es la aplicación que se conecta al servidor y mantiene una copia local del repositorio, así como se encarga, generalmente de la corrección de conflictos y la mayoría de lógica del sistema.
•El servidor: Es el sistema que toma los datos del cliente y los almacena a espera de una o múltiples peticiones de esos datos. Este sistema se encargaría del almacenamiento de las versiones, control de concurrencia, bloqueos y otras características parecidas a las de las bases de datos.
¿Qué limitaciones y características posee?
•El sistema servidor es un repositorio, como los que mantienen los clientes, pero perfectamente sincronizado y sin que dé lugar a conflictos. Es la copia maestra de los datos.
•Cuando un sistema web quiere hacer un listado, puede tomar los datos de este servidor y siempre serán seguros, con lo que no tendrá que resolver conflictos, ni tendrá que hacer mezclas.
•Una copia local debe de poder mezclarse con el repositorio central cuando queramos publicar un conjunto de cambios o cuando queramos tomar la última versión publicada en concordancia con nuestra copia local.
•Es normal ver en muchos de estos sistemas ramificaciones, versiones, etiquetas, o similares, a modo de tener varias copias según nos interese. Estas ramificaciones están en el servidor y en algunos casos puede llegar a ser muy costosa su diferenciación.
Algunos ejemplos de Controladores de Versiones Centralizados:
•Concurrent Versions System (CVS)
•SubVersion
Distribuido
Desarrolladores como Linus Torvalds, Eric S. Raymond y otros más, han desarrollado sistemas distribuidos de control de versiones tales como GIT, Baazaar, Mercurial, darcs, entre otros; estos sistemas se destacan por haber sido desarrollados en un formato distribuido, esto quiere decir que, en sí, no hay un servidor que mantenga una copia del repositorio, sino que está mantenida entre los clientes que estén en uso del repositorio y, al igual que los clientes P2P, mientras más desarrolladores haya conectados, mejor conectividad habrá entre todos.
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 (exclusió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.
Esto da una serie de ventajas al sistema centralizado, como son:
•Disponer de forma distribuida de la información del repositorio al completo, tanto de forma local, como a través de los demás componentes del grupo.
•Cada cambio se va replicando entre los demás equipos distribuidos, a modo de que puedan emplear esos datos y actualizarlos en sus sistemas.
•El sistema de control de versiones distribuido ha sido pensado con la forma de trabajo basada en ramas, unión central en una sola versión (trunk) y liberaciones (o tags). Con lo que cada rama puede identificarse como cada copia distribuida que se use.
•Una máquina servidora puede emplearse, al estar siempre conectada, como otro punto de sincronización, con la ventaja de que, aunque cayera, mientras haya más miembros conectados, el sistema siempre se mantiene activo y con buen ancho de banda.
Algunos ejemplos de Controladores de Versiones Distribuidos:
•Baazaar
•Mercurial
•GIT
Suscribirse a:
Entradas (Atom)
