Subversión de Apache

format_list_bulleted Contenido keyboard_arrow_down

ImprimirCitar

Sistema de versión y control de revisiones de software libre y de código abierto

Apache Subversion (a menudo abreviado SVN, después de su nombre de comando svn) es un sistema de control de versiones y revisión de software distribuido como código abierto bajo la Licencia Apache. Los desarrolladores de software usan Subversion para mantener versiones actuales e históricas de archivos como código fuente, páginas web y documentación. Su objetivo es ser un sucesor mayoritariamente compatible con el ampliamente utilizado Sistema de versiones concurrentes (CVS).

La comunidad de código abierto ha usado Subversion ampliamente: por ejemplo, en proyectos como Apache Software Foundation, Free Pascal, FreeBSD, SourceForge y, de 2006 a 2019, GCC. CodePlex era anteriormente un host común para los repositorios de Subversion.

Subversion fue creado por CollabNet Inc. en 2000 y ahora es un proyecto de Apache de primer nivel que está siendo desarrollado y utilizado por una comunidad global de colaboradores.

Historia

CollabNet fundó el proyecto Subversion en 2000 como un esfuerzo por escribir un sistema de control de versiones de código abierto que funcionaba de forma similar a CVS pero que solucionaba los errores y proporcionaba algunas funciones que faltaban en CVS. En 2001, Subversion había avanzado lo suficiente como para albergar su propio código fuente y, en febrero de 2004, se lanzó la versión 1.0. En noviembre de 2009, Subversion fue aceptado en Apache Incubator: esto marcó el comienzo del proceso para convertirse en un proyecto Apache estándar de alto nivel. Se convirtió en un proyecto Apache de alto nivel el 17 de febrero de 2010.

Versión	Fecha de lanzamiento original	Última versión	Fecha de lanzamiento	Situación
Versión antigua, ya no se mantiene: 1.0	2004-02-23	1.0.9	2004-10-13	Ya no hay apoyo
Versión antigua, ya no se mantiene: 1.1	2004-09-29	1.1.4	2005-04-01	Ya no hay apoyo
Versión antigua, ya no se mantiene: 1.2	2005-05-21	1.2.3	2005-08-19	Ya no hay apoyo
Versión antigua, ya no se mantiene: 1.3	2005-12-30	1.3.2	2006-05-23	Ya no hay apoyo
Versión antigua, ya no se mantiene: 1.4	2006-09-10	1.4.6	2007-12-21	Ya no hay apoyo
Versión antigua, ya no se mantiene: 1,5	2008-06-19	1,5.9	2010-12-06	Ya no hay apoyo
Versión antigua, ya no se mantiene: 1.6	2009-03-20	1.6.23	2013-05-30	Ya no hay apoyo
Versión antigua, ya no se mantiene: 1.7	2011-10-11	1.7.22	2015-08-12	Ya no hay apoyo
Versión antigua, ya no se mantiene: 1.8	2013-06-18	1.8.19	2017-08-10	Ya no hay apoyo
Versión antigua, ya no se mantiene: 1.9	2015-08-05	1.9.12	2019-07-24	Ya no hay apoyo
Versión antigua, ya no se mantiene: 1.10	2018-04-13	1.10.8	2022-04-12	Ya no hay apoyo
Versión antigua, ya no se mantiene: 1.11	2018-10-30	1.11.1	2019-01-11	Ya no hay apoyo
Versión antigua, ya no se mantiene: 1.12	2019-04-24	1.12.2	2019-07-24	Ya no hay apoyo
Versión antigua, ya no se mantiene: 1.13	2019-10-30	1.13.0	2019-10-30	Ya no hay apoyo
Versión estable actual: 1.14	2020-05-27	1.14.2	2022-04-12	Totalmente compatible, LTS
Leyenda: Versión antigua Versión más antigua, todavía mantenida Última versión Última versión de vista previa Liberación del futuro

Las fechas de lanzamiento se extraen de los CAMBIOS de Apache Subversion , que registra todo el historial de versiones.

Características

Commits as true atomic operations (interrupted commit operations in CVS would cause repository inconsistency or corruption).
El sistema mantiene la versión para directorios y algunos metadatos de archivos específicos (ver Propiedades). Los usuarios pueden mover o copiar archivos y directorios enteros muy rápidamente, al tiempo que conservan el historial de revisión completo (como se implementa por una referencia al objeto original).
Versión de enlaces simbólicos.
Soporte nativo para archivos binarios, con almacenamiento binario-diff eficiente en el espacio.
Apache HTTP Servidor como servidor de red, WebDAV/Delta-V para protocolo. También hay un proceso de servidor independiente llamado svnserve que utiliza un protocolo personalizado sobre TCP/IP.
La ramificación es implementada por una copia de un directorio, por lo tanto es una operación barata, independiente del tamaño de archivo.
Nativamente cliente-servidor, diseño de bibliotecas capas.
Protocolo cliente/servidor envía diffs en ambas direcciones.
Salida Parsable, incluyendo salida de registro XML.
Licencia de código abierto – Apache desde la versión 1.7; versiones anteriores utilizan un derivado de la Licencia de Software de Apache 1.1.
Mensajes del programa internacionalizados.
Locking de archivos para archivos inmergeable ("reservido checkouts").
Autorización basada en el camino.
Limitaciones de idiomas para C#, PHP, Python, Perl, Ruby y Java.
Soporte completo MIME – los usuarios pueden ver o cambiar el tipo MIME de cada archivo, con el software saber qué tipos MIME pueden tener sus diferencias de versiones anteriores mostradas.
Rastreo de fusión – fusiones entre ramas serán rastreados, esto permite la fusión automática entre ramas sin decirle a Subversion qué hace y no necesita ser fusionado.
Changelists to organize commits into commit groups.

Tipos de repositorio

Subversion ofrece dos tipos de almacenamiento de repositorio.

Berkeley DB (obsoleto)

El desarrollo original de Subversion utilizó el paquete Berkeley DB. Subversion tiene algunas limitaciones con el uso de Berkeley DB cuando un programa que accede a la base de datos falla o termina a la fuerza. No se produce pérdida ni corrupción de datos, pero el repositorio permanece fuera de línea mientras Berkeley DB reproduce el diario y limpia los bloqueos pendientes. La forma más segura de usar Subversion con un repositorio de base de datos de Berkeley involucra un solo proceso de servidor que se ejecuta como un usuario (en lugar de a través de un sistema de archivos compartido). El backend de Berkeley DB quedó obsoleto en la versión 1.8.

FSFS

En 2004, se desarrolló un nuevo subsistema de almacenamiento y se denominó FSFS. Funciona más rápido que el backend de Berkeley DB en directorios con una gran cantidad de archivos y ocupa menos espacio en disco. debido a la menor tala.

A partir de Subversion 1.2, FSFS se convirtió en el almacén de datos predeterminado para los nuevos repositorios.

La etimología de "FSFS" se basa en el uso que hace Subversion del término "sistema de archivos" para su sistema de almacenamiento de repositorio. FSFS almacena su contenido directamente dentro del sistema de archivos del sistema operativo, en lugar de un sistema estructurado como Berkeley DB. Por lo tanto, es un sistema de archivos "[Subversion] sobre el sistema de archivos".

FSX

Se está desarrollando un nuevo sistema de archivos, llamado FSX, para eliminar algunas limitaciones de FSFS. A partir de la versión 1.9, no se consideró listo para la producción.

Acceso al repositorio

El acceso a los repositorios de Subversion puede realizarse mediante:

Sistema de archivos o sistema de red local, acceso directo por cliente. Este modo utiliza el file:///path esquema de acceso.
WebDAV/Delta-V (sobre http o https) utilizando el mod_dav_svn módulo para Apache 2. Este modo utiliza el http://host/path esquema de acceso o https://host/path para conexiones seguras usando ssl.
Protocolo "svn" personalizado (puerto predeterminado 3690), utilizando texto simple o sobre TCP/IP. Este modo utiliza cualquiera svn://host/path esquema de acceso para transporte no cifrado o svn+ssh://host/path esquema para túnelear sobre ssh.

Los tres medios pueden acceder a los repositorios FSFS y Berkeley DB.

Cualquier versión 1.x de un cliente puede funcionar con cualquier servidor 1.x. Los clientes y servidores más nuevos tienen funciones y capacidades de rendimiento adicionales, pero tienen soporte alternativo para clientes/servidores más antiguos.

Capas

Internamente, un sistema Subversion comprende varias bibliotecas dispuestas como capas. Cada uno realiza una tarea específica y permite a los desarrolladores crear sus propias herramientas al nivel deseado de complejidad y especificidad.

Fs

El nivel más bajo; implementa el sistema de archivos versionado que almacena los datos del usuario.

Repos

Preocupada por el repositorio construido alrededor del sistema de archivos. Tiene muchas funciones de ayuda y maneja los diversos "hooks" que un repositorio puede tener, por ejemplo, scripts que funcionan cuando se realiza una acción. Juntos, Fs y Repos constituyen la "interfase del sistema de ficheros".

mod_dav_svn

Proporciona acceso WebDAV/Delta-V a través de Apache 2.

Ra

Manijas "acceso de depósito", tanto local como remota. Desde este punto en adelante, los repositorios se refieren a utilizar URLs, por ejemplo.

archivo:///path/ para el acceso local,
http://host/path/ o https://host/path/ para acceso WebDAV, o
svn://host/path/ o svn+ssh://host/path/ para el protocolo SVN.

Cliente, Wc: El nivel más alto. Se abstrae el acceso al repositorio y proporciona tareas comunes al cliente, como autenticar usuarios o comparar versiones. Los clientes de subversión usan la biblioteca Wc para administrar la copia de trabajo local.

Sistema de archivos

Se puede ver el sistema de archivos de Subversion como "bidimensional". Se utilizan dos coordenadas para abordar sin ambigüedades los elementos del sistema de archivos:

Camino (carril regular de sistema de archivos de sistema operativo similar a unix)
Revisión

Cada revisión en un sistema de archivos de Subversion tiene su propia raíz, que se utiliza para acceder al contenido de esa revisión. Los archivos se almacenan como enlaces al cambio más reciente; por lo tanto, un repositorio de Subversion es bastante compacto. El sistema consume espacio de almacenamiento proporcional al número de cambios realizados, no al número de revisiones.

El sistema de archivos de Subversion utiliza transacciones para mantener los cambios atómicos. Una transacción opera en una revisión específica del sistema de archivos, no necesariamente la más reciente. La transacción tiene su propia raíz, en la que se realizan los cambios. Entonces se confirma y se convierte en la última revisión, o se aborta. La transacción es en realidad un objeto de sistema de archivos de larga duración; un cliente no necesita confirmar o cancelar una transacción en sí mismo, sino que también puede comenzar una transacción, salir y luego puede volver a abrir la transacción y continuar usándola. Potencialmente, varios clientes pueden acceder a la misma transacción y trabajar juntos en un cambio atómico, aunque ningún cliente existente expone esta capacidad.

Propiedades

Una característica importante del sistema de archivos de Subversion son las propiedades: pares de texto simples nombre=valor. La mayoría de las propiedades ocurren en las entradas del sistema de archivos (es decir, archivos y directorios). Estos se versionan al igual que otros cambios en el sistema de archivos. El cliente de Subversion reserva el 'svn:' prefijo para propiedades integradas, pero se pueden usar otros nombres para definir propiedades personalizadas.

svn:ejecutable: Hace un archivo sobre copias de trabajo organizadas por Unix, cuando es compatible con el sistema de archivos.
svn:mime-type: Almacena el tipo de medios de Internet ("tipo MIME") de un archivo. Afecta el manejo de los diffs y la fusión.
svn:ignore: Una lista de patrones de nombre de archivo para ignorar en un directorio. Similar a los CVS .cvsignore archivo.
svn: palabras clave: Una lista palabras clave sustituir en un archivo cuando se hacen cambios. El propio archivo también debe hacer referencia a las palabras clave como $keyword$ o $keyword:...$. Esto se utiliza para mantener cierta información (por ejemplo, autor, fecha del último cambio, número de revisión) en un archivo sin intervención humana.
El mecanismo de sustitución de palabras clave se origina de RCS y de CVS.
svn: estilo eol: Hace que el cliente convierta los caracteres finales de línea en archivos de texto. Se utiliza cuando se necesita la copia de trabajo con un estilo EOL específico. "nativo" se utiliza comúnmente, por lo que los EOL coinciden con el estilo OS EOL del usuario. Los repositorios pueden requerir esta propiedad en todos los archivos para evitar finales de línea inconsistentes, lo que puede causar un problema en sí mismo.
svn:externals: Permite que partes de otros repositorios se registren automáticamente en un subdirectorio.
svn:needs-lock: Especifica que un archivo debe ser revisado con permisos de archivo establecidos para leer solo. Esto está diseñado para su uso con el mecanismo de bloqueo. El permiso de sólo lectura recuerda a uno para obtener una cerradura antes de modificar el archivo: la obtención de una cerradura hace que el archivo sea complaciente, y la liberación de la cerradura lo hace solo de nuevo. Las cerraduras sólo se aplican durante una operación de confirmación. Las cerraduras se pueden utilizar sin establecer esta propiedad. Sin embargo, eso no se recomienda, porque introduce el riesgo de que alguien modifique un archivo bloqueado; sólo descubrirán que ha sido bloqueado cuando su compromiso falla.
svn:especial: Esta propiedad no está destinada a ser establecida o modificada directamente por los usuarios. A partir de 2010 sólo se utiliza para tener enlaces simbólicos en el repositorio. Cuando se agrega un enlace simbólico al repositorio, se crea un archivo que contiene el objetivo de enlace con este conjunto de propiedades. Cuando un sistema similar a Unix revisa este archivo, el cliente lo convierte en un enlace simbólico.
svn:mergeinfo: Se utiliza para rastrear datos de fusión (números de revisión) en Subversion 1.5 (o posterior). Esta propiedad se mantiene automáticamente por merge comando, y no se recomienda cambiar su valor manualmente.

Subversion también usa propiedades en las propias revisiones. Al igual que las propiedades anteriores en las entradas del sistema de archivos, los nombres son completamente arbitrarios, y el cliente de Subversion usa ciertas propiedades con el prefijo 'svn:'. Sin embargo, estas propiedades no están versionadas y se pueden cambiar más tarde si lo permite un enlace de cambio previo a revprop.

svn:date: El sello de fecha y hora de una revisión.
svn:author: El nombre del usuario que presentó el(s) cambio(s).
svn:log: La descripción proporcionada por el usuario del cambio (s).

Bifurcación y etiquetado

Subversion utiliza el modelo de bifurcación entre archivos de Perforce para implementar bifurcaciones y etiquetado. Una rama es una línea separada de desarrollo. El etiquetado se refiere a etiquetar el repositorio en un momento determinado para que se pueda encontrar fácilmente en el futuro. En Subversion, la única diferencia entre ramas y etiquetas es cómo se usan.

Se configura una nueva rama o etiqueta usando la "svn copy" comando, que debe usarse en lugar del mecanismo del sistema operativo nativo. El directorio copiado está vinculado al original en el repositorio para preservar su historial, y la copia ocupa muy poco espacio adicional en el repositorio.

Todas las versiones de cada rama mantienen el historial del archivo hasta el momento de la copia, además de los cambios realizados desde entonces. Uno puede "fusionar" cambia de nuevo al tronco o entre las ramas.

Visualización de un sencillo proyecto Subversion

Limitaciones y problemas

Un problema conocido en Subversion afecta la implementación de la operación de cambio de nombre de archivos y directorios. A partir de 2014, Subversion implementa el cambio de nombre de archivos y directorios como una "copia" al nuevo nombre seguido de "eliminar" del antiguo nombre. Solo cambian los nombres, todos los datos relacionados con el historial de edición siguen siendo los mismos y Subversion seguirá usando el nombre antiguo en las revisiones anteriores del "árbol". Sin embargo, Subversion puede confundirse cuando un movimiento entra en conflicto con ediciones realizadas en otros lugares, tanto para confirmaciones regulares como al fusionar ramas. El lanzamiento de Subversion 1.5 abordó algunos de estos escenarios, mientras que otros siguieron siendo problemáticos. El lanzamiento de Subversion 1.8 abordó algunos de estos problemas al hacer que los movimientos fueran una operación de primera clase en el cliente, pero todavía se trata como copiar+eliminar en el repositorio.

A partir de 2013, Subversion carece de algunas funciones de gestión y administración de repositorios. Por ejemplo, alguien puede desear editar el repositorio para eliminar permanentemente todos los registros históricos de ciertos datos. Subversion no tiene soporte incorporado para lograr esto de manera simple.

Subversion almacena copias adicionales de datos en la máquina local, lo que puede convertirse en un problema con proyectos o archivos muy grandes, o si los desarrolladores trabajan en varias sucursales simultáneamente. En versiones anteriores a la 1.7, estos directorios .svn en el lado del cliente podrían corromperse debido a la actividad desacertada del usuario, como las operaciones globales de búsqueda/reemplazo. A partir de la versión 1.7, Subversion utiliza una única carpeta centralizada .svn por área de trabajo.

Subversion no almacena las horas de modificación de los archivos. Como tal, un archivo extraído de un repositorio de Subversion tendrá el código 'actual' fecha (en lugar de la hora de modificación en el repositorio), y un archivo registrado en el repositorio tendrá la fecha de registro (en lugar de la hora de modificación del archivo que se está registrando). Esto puede no ser siempre lo que se desea. Para mitigar esto, existen herramientas de terceros que permiten conservar el tiempo de modificación y otros metadatos del sistema de archivos. Sin embargo, también es importante dar a los archivos extraídos una fecha actual: así es como herramientas como make(1) se darán cuenta de un archivo modificado para reconstruirlo.

Subversion utiliza un modelo de control de revisión centralizado. Ben Collins-Sussman, uno de los diseñadores de Subversion, cree que un modelo centralizado ayudaría a evitar que los "programadores inseguros" de ocultar su trabajo de otros miembros del equipo. Algunos usuarios de sistemas de control de versiones ven el modelo centralizado como perjudicial; famoso, Linus Torvalds atacó el modelo de Subversion y sus desarrolladores.

Subversion a menudo no maneja bien la normalización de nombres de archivos realizada por el sistema de archivos HFS+. Esto puede causar problemas cuando los archivos con caracteres acentuados en sus nombres se agregan al repositorio en un sistema de archivos que no es HFS+ y luego el repositorio se usa con HFS+.

Etiquetas y ramas de Subversion

Los números de revisión son difíciles de recordar en cualquier sistema de control de versiones. Por esta razón, la mayoría de los sistemas ofrecen etiquetas simbólicas como referencias fáciles de usar para ellos. Subversion no tiene esa función y lo que su documentación recomienda usar en su lugar es de naturaleza muy diferente. En lugar de implementar etiquetas como referencias a puntos en el historial, Subversion recomienda hacer copias instantáneas en un subdirectorio bien conocido ("tags/") en el espacio del árbol del repositorio. Solo están disponibles unas pocas referencias predefinidas: HEAD, BASE, PREV y COMPROMETIDO.

Esta proyección de la historia al espacio tiene varios problemas:

Cuando se toma una instantánea, el sistema no asigna ningún significado especial al nombre de la etiqueta/snapshot. Esta es la diferencia entre Copia y a referencia. La revisión se registra y la instantánea se puede acceder por URL. Esto hace que algunas operaciones sean menos convenientes y otras imposibles. Por ejemplo, una ingenua svn diff -r tag1:tag2 myfile no funciona; es un poco más complicado que eso para lograr, requiriendo que el usuario conozca y introduzca URL/paths a las instantáneas en lugar de sólo los nombres: svn diff /myfile /myfile. Otras operaciones como por ejemplo svn log -r tag1:tag2 myfile son imposibles.
Cuando dos tipos de objetos (idealmente independientes) viven en el árbol del repositorio, se puede realizar una "lucha a la parte superior". En otras palabras, a menudo es difícil decidir a qué nivel crear tags/ subdirectorio:
tronco/ /componenteFoo/ /componentebar/ tags/ /1.1/ /componenteFoo/ /componentebar/
o
componenteFoo/ /tronco/ /tags/ /1.1/ componentebar/ /tronco/ /tags/ /1.1/
Las etiquetas, por su definición convencional, son de sólo lectura y peso ligero, en el repositorio y cliente. Las copias de subversión no son sólo de lectura, y mientras que son ligeras en el repositorio, son increíblemente pesados en el cliente.

Para abordar estos problemas, los carteles en las listas de correo de Subversion han sugerido una nueva característica llamada "etiquetas" o "alias". Las etiquetas SVN se parecerían más a las "etiquetas" de otros sistemas como CVS o Git. El hecho de que Subversion tenga números de revisión globales abre el camino a una etiqueta → implementación de revisión muy simple. Sin embargo, a partir de 2013, no se han realizado avances y las etiquetas simbólicas no están en la lista de las características más buscadas.

Desarrollo e implementación

CollabNet ha seguido participando en Subversion, pero el proyecto se ejecuta como una comunidad independiente de código abierto. En noviembre de 2009, el proyecto fue aceptado en Apache Incubator, con el objetivo de formar parte de los esfuerzos de Apache Software Foundation. Desde marzo de 2010, el proyecto se conoce formalmente como Apache Subversion y forma parte de los proyectos de nivel superior de Apache.

En octubre de 2009, WANdisco anunció la contratación de los encargados principales de Subversion cuando la empresa pasó a convertirse en uno de los principales patrocinadores corporativos del proyecto. Esto incluyó a Hyrum Wright, presidente de Subversion Corporation y gerente de lanzamiento del proyecto Subversion desde principios de 2008, quien se unió a la compañía para liderar su equipo de código abierto.

La comunidad de código abierto de Subversion no proporciona archivos binarios, pero los usuarios potenciales pueden descargar archivos binarios de voluntarios. Si bien el proyecto Subversion no incluye una interfaz gráfica de usuario (GUI) oficial para usar con Subversion, terceros han desarrollado varias GUI diferentes, junto con una amplia variedad de software auxiliar adicional.

El trabajo anunciado en 2009 incluía SubversionJ (una API de Java) y la implementación del comando Obliterate, similar al proporcionado por Perforce. Ambas mejoras fueron patrocinadas por WANdisco.

Los autores de Subversion normalmente tienen al menos una o dos funciones nuevas en desarrollo activo al mismo tiempo. La versión 1.7 de Subversion en octubre de 2011 incluyó un transporte HTTP simplificado para mejorar el rendimiento y una biblioteca de copia de trabajo reescrita.

En 2002, se llevó a cabo un concurso de diseño para seleccionar el logotipo de Subversion. Las entradas originales se pueden encontrar aquí, así como los votos para cada logotipo. El logotipo actual recibió la mayor cantidad de votos en el concurso.

Contenido relacionado

Más resultados...