| subversión | |
|---|---|
| Tipo de | sistema de control de versiones centralizado [d] , proyecto Apache Foundation [d] ysoftware de código abierto |
| Autor | Red de colaboración [d] |
| Desarrollador | Fundación de software Apache |
| Escrito en | C [4] [5] , Python [4] , C++ [6] [7] y Java [6] [7] |
| Sistema operativo | GNU/Linux [8] , Microsoft Windows [8] , macOS [8] y BSD [8] |
| Primera edición | 20 de octubre de 2000 [1] |
| ultima versión |
|
| Formatos de archivo legibles | Formato de volcado SVN (v1) [d] , formato de volcado SVN (v2) [d] , formato de volcado SVN (v3) [d] y formato de volcado SVN (genérico) [d] |
| Formatos de archivo generados | Formato de volcado SVN (v1) [d] , formato de volcado SVN (v2) [d] , formato de volcado SVN (v3) [d] y formato de volcado SVN (genérico) [d] |
| Licencia | Licencia Apache 2.0 [9] |
| Sitio web | subversion.apache.org _ |
| Archivos multimedia en Wikimedia Commons | |
Subversion [10] (también conocido como " SVN " [11] ) es un sistema de control de versiones centralizado gratuito lanzado oficialmente en 2004 por CollabNet . Desde 2010, Subversion ha sido un proyecto de Apache Software Foundation y se llama oficialmente Apache Subversion ( marca registrada [12] ).
El objetivo del proyecto al comienzo del desarrollo era reemplazar [13] [14] el Sistema de Versiones Concurrentes (CVS) entonces extendido , que ahora se considera obsoleto [15] [16] [17] . Subversion implementa todas las características principales de CVS y está libre de algunas de las deficiencias de este último.
Algunas comunidades de código abierto todavía utilizan Subversion (incluidas las que antes usaban CVS ), pero casi todos los proyectos importantes se han trasladado a DVCS . Entre los últimos usuarios de Subversion entre los proyectos abiertos se mantiene FreeBSD , pero también anunciaron una transición a Git [18] , y, por ejemplo, Free Pascal . Subversion ha sido utilizado durante bastante tiempo por proyectos tan conocidos como Apache , GCC , FFmpeg , LLVM . Subversion también se usa en proyectos privados y en el mundo corporativo, pero es difícil medir cuán ampliamente. El alojamiento de Subversion , incluso para proyectos de código abierto, también lo proporcionan los proyectos de alojamiento populares SourceForge.net , Tigris.org , Google Code y BountySource .
En 2007, Forrester , una empresa de análisis , calificó a Subversion como "el líder único en la categoría de gestión de configuración de software independiente (SCM) y un gran contribuyente en la categoría de gestión de cambios y configuración de software (SCCM)" al comparar las ventajas y desventajas de varios sistemas _ [19]
Según las estadísticas sobre el uso de paquetes de Linux , distribuciones Debian [20] y Ubuntu [21] , el número de usuarios activos de Subversion alcanzó su punto máximo alrededor de 2010 y ha comenzado a disminuir desde 2016. Sin embargo, todavía hay más proyectos que usan Subversion que CVS , Mercurial y Bazaar (hasta agosto de 2019 ).
La documentación oficial está posicionada [22] por el libro publicado por O'Reilly Media , que está disponible gratuitamente [23] y los autores lo agregan a medida que se lanzan nuevas versiones de SVN. También publica sus traducciones a varios idiomas, incluido el ruso, pero a pesar de que las versiones en inglés del libro ahora describen las versiones 1.8 y 1.7, solo hay libros en ruso que describen versiones hasta la 1.4 inclusive [24] .
El desarrollo de Subversion comenzó en el año 2000 por iniciativa y con el apoyo financiero de CollabNet. Los iniciadores del proyecto querían crear un sistema de control de versiones gratuito , básicamente similar a CVS, pero sin sus errores e inconvenientes . En ese momento no había mejores programas de esta clase con licencia libre, CVS era el estándar de facto entre los desarrolladores de software libre. Al elegirlo como línea de base, los desarrolladores de Subversion esperaban simplificar el desarrollo aprovechando conceptos ya probados, mientras que al mismo tiempo facilitaba la migración de muchos usuarios de CVS al nuevo sistema. [25]
Principales acontecimientos en la historia del desarrollo de Subversion.
Subversion es un sistema centralizado (a diferencia de los sistemas distribuidos como Git o Mercurial ), lo que significa que los datos se almacenan en un único repositorio. El repositorio se puede ubicar en un disco local o en un servidor de red .
Trabajar en Subversion no es muy diferente de trabajar en otros sistemas de control de versiones centralizados. Los clientes copian archivos del almacén para crear copias de trabajo locales, luego realizan cambios en las copias de trabajo y confirman esos cambios en el almacén. Varios clientes pueden acceder al almacenamiento al mismo tiempo. Subversion utiliza principalmente el modelo copiar-modificar-fusionar para colaborar en archivos . Además, para los archivos que no se pueden fusionar (varios formatos de archivos binarios), puede usar el modelo de bloqueo, modificación y desbloqueo .
Al guardar nuevas versiones, se utiliza la compresión delta : el sistema encuentra diferencias entre la nueva versión y la anterior y las escribe solo, evitando la duplicación de datos.
Cuando se utiliza el acceso WebDAV, también se admite el control de versiones transparente: si cualquier cliente WebDAV se abre para escribir y luego guarda un archivo almacenado en un recurso compartido de red, se crea automáticamente una nueva versión.
Subversion ofrece dos opciones para organizar repositorios [40] . Los repositorios del primer tipo se utilizan para almacenar una base de datos basada en Berkeley DB , los repositorios del segundo tipo son archivos ordinarios de un formato especial (el acceso a los datos se organiza utilizando sus propias bibliotecas, sin utilizar bases de datos de terceros). Los desarrolladores de Subversion a menudo se refieren al almacenamiento como un "sistema de archivos", razón por la cual el segundo tipo se llama FSFS, lo que significa un sistema de archivos (versionado) ( English File System ) encima de un sistema de archivos (regular).
Ambos tipos de repositorios brindan suficiente confiabilidad cuando se organizan adecuadamente [41] (Berkeley DB usa bloqueos de archivos, por lo que no se puede usar en algunos sistemas de archivos de red que no admiten bloqueos), cada uno de ellos tiene sus propias ventajas y desventajas. Se cree que FSFS es más fácil de configurar correctamente, requiere menos atención por parte del administrador. Además, antes de la versión 1.4, los repositorios que usaban Berkeley DB podían, bajo ciertas condiciones, terminar en el llamado estado de cuña ; se requirió la intervención del administrador para restaurar su funcionalidad.
A partir de la versión 1.2, FSFS se usa de forma predeterminada para nuevos almacenamientos. Con la versión 1.8, el uso de Berkeley DB quedó obsoleto [37] . Es posible que las nuevas funciones que se agregarán en versiones futuras no funcionen en servidores que utilizan Berkeley DB. El soporte para Berkeley DB puede suspenderse en el futuro.
Subversion proporciona las siguientes formas de acceder a un repositorio:
Todos estos métodos se pueden utilizar para trabajar con ambos tipos de repositorios (FSFS y Berkeley DB). Se pueden usar diferentes métodos al mismo tiempo para acceder al mismo repositorio.
Desde la perspectiva del usuario, el repositorio de Subversion es un sistema de archivos "bidimensional" . Los objetos de un repositorio ( archivos y directorios ) se identifican mediante dos " coordenadas ": un nombre y un número de revisión . En otras palabras, el repositorio es una matriz de instantáneas (revisiones) de un árbol de archivos y directorios, indexados por el número de revisión. Cada una de estas instantáneas es un sistema de archivos normal (unidimensional).
Si es necesario indicar una revisión específica de un objeto, se utiliza una entrada del formulario: имя@ревизия, por ejemplo, /main.c@29 el archivo /main.c en la revisión 29. Tal indicación de la revisión utilizada para aclarar el nombre se denomina peg revisión _
En la fig. 1 muestra una representación gráfica del sistema de archivos: el eje vertical corresponde al conjunto de nombres, el eje horizontal corresponde al conjunto de revisiones.
Nombres de archivoEl nombre de un objeto del sistema de archivos en Subversion se forma de acuerdo con las mismas reglas que en los sistemas operativos similares a UNIX: solo hay un directorio raíz, los elementos de la ruta están separados por una barra inclinada ("/"). Los objetos del sistema de archivos son archivos y directorios (así como enlaces simbólicos , que se emulan desde archivos normales configurando el atributo svn:special).
Números de revisiónEl número de revisión en Subversion es un número natural (o 0 para la primera revisión) que indica el número de estado del repositorio a medida que cambian los datos que contiene. Cada confirmación exitosa genera exactamente una nueva revisión en el repositorio, por lo que la N- ésima revisión es el estado del repositorio después de la N- ésima confirmación.
En Subversion, una revisión caracteriza el estado no de un solo archivo, sino del repositorio completo como un todo. Por ejemplo, la revisión 32 (punteada en la figura) es el estado de cuatro archivos y dos directorios que existían en el repositorio en ese momento.
El número de revisión es análogo al tiempo en el sentido de que los números de revisión más bajos corresponden a estados anteriores del repositorio y los números de revisión más altos corresponden a estados posteriores.
El número de revisión se puede considerar como una especie de marca de tiempo en el historial del repositorio. Además, cada número de revisión tiene un valor absoluto asociado con el momento en que se realizó la revisión ( propiedad svn:date ). Sin embargo, especificar el número de revisión es más conveniente que especificar la hora, ya que no hay confusión con las zonas horarias, la entrada del número es más corta y el número de revisión no se puede cambiar.
Revisiones operativas y básicasEl número de revisión se utiliza en dos contextos diferentes :
Una revisión se denomina operativa si especifica la revisión o el rango de revisiones a las que se aplicará la operación , por ejemplo:
svn log -r 199:230 http://alguna.rutaEn este ejemplo, el comando se ejecuta svn logpara un rango de revisiones 199:230, que es el rango de revisiones en línea.
Sin embargo, especificar solo el nombre del archivo y la revisión en línea a veces puede apuntar de manera ambigua a los objetos del repositorio. Por ejemplo, en la situación mostrada en la Fig. 2, existe una ambigüedad al ejecutar el siguiente comando:
svn log -r 29:33 http://alguna.ruta/bar.txtEl comando especifica un rango de revisiones en línea ( 29:33), pero las áreas resaltadas en azul y verde en la figura pueden considerarse igualmente como el historial del archivo /bar.txten el rango de revisión 29:33. En tales casos, también es necesario especificar la revisión del pivote para resolver la ambigüedad. La revisión principal es el número de revisión especificado además de la URL del objeto del sistema de archivos (usando la URL@ревизияnotación " "). El nombre proviene de la palabra inglesa peg , que se puede traducir como "rod" o "peg". La revisión pivote marca la cadena de estados a la que pertenece el par especificado URL@ревизияy, por lo tanto, identifica de forma única el objeto del repositorio al que se aplicará el comando. En el ejemplo a continuación, el primer comando imprimirá la historia resaltada en azul en la figura y el segundo comando imprimirá la historia resaltada en verde:
svn log -r 29:33 http://alguna.ruta/archivo.txt@32 svn log -r 29:33 http://alguna.ruta/bar.txt@34El último estado del objeto de interés debe especificarse como la revisión principal. La razón de esto es que la cadena de estado se rastrea de forma única "hacia atrás" pero no "hacia adelante". Por ejemplo, la URL con la revisión dinámica http://some.path/foo.txt@31 pertenece a dos cadenas de estado (resaltadas en verde y gris respectivamente). De estas dos cadenas, la URL especificada se dirige a la cadena gris, es decir, cuando se avanza "hacia adelante" desde la revisión principal, se ignoran las operaciones de copia.
Operaciones en el sistema de archivosLas siguientes operaciones se pueden realizar en los objetos del sistema de archivos en el repositorio de Subversion [42] (consulte la Figura 1). Los corchetes indican el nombre abreviado de la operación en la notación del comando svn status.
Una copia de trabajo es una copia local de un fragmento de datos del repositorio creado por el programa cliente de Subversion que contiene, además de los datos en sí, alguna información de servicio (directorios ocultos denominados .svn). La información del servicio es necesaria para el correcto funcionamiento de la copia de trabajo; no se puede cambiar nada en los datos de servicio. La unidad de datos más pequeña que se puede recuperar de un repositorio como copia de trabajo es un directorio. Es posible que el contenido de un directorio no se extraiga por completo: por ejemplo, se pueden excluir archivos o subdirectorios individuales. Sin embargo, no es posible extraer un solo archivo del almacén como copia de trabajo.
Cualquier subdirectorio de una copia de trabajo de Subversion 1.6 y anterior también es una copia de trabajo completa, porque cada directorio contiene sus datos de mantenimiento (directorios .svn). Desde la versión 1.7, cada copia de trabajo tiene solo un directorio .svnen la raíz de su directorio.
La copia de trabajo es autónoma en el sentido de que Subversion no almacena ningún dato relacionado con la copia de trabajo fuera de ella. Por lo tanto, al tener una copia de trabajo, puede hacer varias copias más simplemente copiando sin gastar tráfico de red.
En los directorios de servicio de la copia de trabajo, entre otras cosas, se almacena la llamada copia limpia ( ing. copia prístina ): los archivos de la copia de trabajo en forma no modificada, tal como se extrajeron del repositorio (para svn esto es una revisión denominada BASE). Tener una copia limpia le permite ver y revertir rápidamente los cambios locales sin acceder al repositorio. Sin embargo, el tamaño de la copia de trabajo en el disco es aproximadamente el doble (datos + copia limpia de datos) que el tamaño de los propios datos. Este enfoque se debe al hecho de que los recursos de disco son más baratos y más accesibles que los recursos de red de datos .
Por lo general, la creación de una copia de trabajo es el primer paso necesario para confirmar los cambios locales, ya que solo los cambios realizados en la copia de trabajo se pueden confirmar en el repositorio. La excepción son las operaciones que se pueden realizar directamente en el almacén sin crear una copia de trabajo.
TransaccionesEl almacenamiento en Subversion está organizado en forma de transacciones con atomicidad y propiedades de aislamiento del conjunto de propiedades ACID . Así, el sistema de control de versiones garantiza la integridad, consistencia y disponibilidad del repositorio en todo momento.
Estas propiedades no están garantizadas para una copia de trabajo de Subversion ; a diferencia de un repositorio, puede estar en un estado intermedio o bloqueado si falla o se interrumpe (es decir, deberá restaurarse mediante un comando svn cleanupo volver a crearse antes de continuar).
Formularios de comando locales y remotosTodos los comandos de cliente de Subversion se pueden dividir en los siguientes grupos:
Formalmente, Subversion no impone ninguna restricción sobre la estructura de archivos del proyecto; puede ser cualquier cosa dentro del marco de las reglas para nombrar objetos en el sistema de archivos. Sin embargo, existen pautas para facilitar el trabajo con ramas y etiquetas. En el caso más simple, se recomienda crear al menos tres subdirectorios en el directorio raíz del repositorio:
/. trunk branches tagsToda la estructura de archivos del proyecto (la línea de desarrollo principal) debe estar contenida en el subdirectorio trunk, el subdirectorio branchesdebe contener las ramas del proyecto y tags las etiquetas . Por ejemplo, la siguiente estructura de directorios del repositorio:
/. trunk branches branch_1 tags tag_1 tag_2
asume que el proyecto ( trunk) tiene una rama “ branch_1” y dos etiquetas “ tag_1” y “ tag_2”. Cada uno de estos directorios ( , y trunk) branch_1contiene una copia de la versión correspondiente del proyecto. tag_1tag_2
Si hay varios (sub)proyectos en el repositorio, se crea la siguiente estructura de subdirectorios para cada (sub)proyecto:
/. project1 trunk branches tags project2 trunk branches tagsEs decir, el directorio raíz contiene directorios de proyectos, y cada uno de ellos tiene su propio trunk, branches, tags, relacionado únicamente con este proyecto. Las estructuras de directorios de almacenamiento descritas son solo ejemplos; en la práctica, el almacenamiento se puede organizar de la manera que mejor se adapte a un caso particular dado. [43] [44]
Otra forma de almacenar varios proyectos es crear varios repositorios. Los proyectos que no estén relacionados de ninguna manera deben ubicarse en diferentes repositorios, ya que no se pueden realizar operaciones de copia, movimiento y fusión entre repositorios. Se pueden fusionar varios repositorios en uno, si es necesario, conservando el historial de revisiones (importando con el comando svnadmin loadcon el parámetro --parent-dir).
SucursalesSubversion usa un modelo de "archivo" (igual que Perforce [45] ) para implementar ramas y etiquetas, es decir, una rama es solo un directorio (también puede crear una rama desde un solo archivo en lugar de un directorio). El comando crea una nueva rama svn copy. Se puede crear una rama en cualquier directorio de repositorio, pero tiene sentido seguir las convenciones descritas anteriormente sobre dónde crear nuevas ramas. Para obtener más información sobre las sucursales, consulte Ramificación y fusión .
EtiquetasLa creación de una etiqueta también se realiza con el comando svn copy, es decir, técnicamente es lo mismo que crear una rama. La única diferencia está en el método de uso: se supone que nadie cambiará los datos en la etiqueta (comprometerá cambios). Por ejemplo, en la fig. 1 etiqueta creada en la revisión 29: directorio /trunkde la revisión 27 copiado con el nombre /tags/R1. Ahora, si no cambia los datos en el directorio /tags/R1, seguirá siendo para siempre una copia exacta del directorio /trunk@27, es decir, será una etiqueta .
El concepto de etiquetas utilizado en Subversion es diferente del concepto de etiquetas en otros sistemas de control de versiones. Normalmente, una etiqueta es un nombre simbólico que se refiere a un conjunto de archivos y su estado. En Subversion, una etiqueta copia un conjunto de archivos y su estado. Las etiquetas de copia en Subversion tienen sus ventajas y desventajas.
ventajas:
Defectos:
Una de las características importantes de Subversion es el soporte para propiedades, es decir, pares de texto de nombre = valor , que se pueden establecer en objetos en la tienda. Las propiedades se usan en dos contextos diferentes: para objetos del sistema de archivos y para revisiones.
Propiedades de los objetos del sistema de archivosA cada archivo o directorio de un almacén se le puede asignar un conjunto de propiedades. Los cambios de propiedad se almacenan en el historial de la misma manera que los cambios en el sistema de archivos. Los usuarios pueden establecer propiedades con cualquier nombre; también hay un conjunto predefinido de propiedades de utilidades que utiliza el programa cliente de Subversion (los nombres de las propiedades de utilidades tienen el prefijo "svn:").
Propiedades de archivo svn:executable Hace que el archivo sea ejecutable (para copias de trabajo en sistemas operativos de la familia UNIX ). svn:mime-type Almacena el tipo MIME del archivo. Afecta la forma en que funcionan los comandos que muestran diferencias de archivos y combinan cambios (fusión). svn:keywords Lista de palabras clave ( ing. keywords ), que serán reemplazadas en el archivo con los valores correspondientes. Para que se produzca la sustitución, la palabra clave debe estar presente en el archivo como un archivo $keyword$. Se utiliza para actualizar automáticamente los valores de un archivo que cambian de una versión a otra (por ejemplo, el número de revisión). svn:eol-style Especifica la regla para convertir caracteres de fin de línea ( EOL ) en un archivo de texto . Se utiliza en los casos en que el archivo debe tener un tipo de carácter EOL específico. Por lo general, se usa "nativo"; en este caso, el tipo de caracteres de final de línea corresponde al adoptado en el sistema operativo en el que se crea la copia de trabajo. svn:needs-lock Indica que el archivo será de solo lectura cuando se recupere del almacenamiento. Esta propiedad está pensada para usarse junto con el mecanismo de bloqueo . Denegar la escritura en un archivo es un recordatorio para adquirir un bloqueo en el archivo antes de editarlo: cuando se adquiere un bloqueo, el programa cliente de Subversion hace que el archivo se pueda escribir automáticamente (liberar el bloqueo nuevamente hace que el archivo no se pueda modificar). Los bloqueos se pueden utilizar sin establecer esta propiedad. Sin embargo, esto no se recomienda, ya que existe el riesgo de que otro usuario comience a editar el archivo bloqueado, y esto solo se descubrirá cuando se confirmen los cambios. svn:special La propiedad no está destinada a ser configurada o modificada por los usuarios. Actualmente se utiliza para almacenar enlaces simbólicos en el repositorio. Cuando se agrega un enlace simbólico a un repositorio, se crea un archivo en el repositorio con la extensión svn:special. Cuando este archivo se desprotege en un sistema similar a UNIX , el programa cliente de Subversion lo vuelve a convertir en un enlace. svn:mergeinfo Almacena información sobre qué rutas se fusionaron en este archivo. La propiedad se introdujo en la versión 1.5, se utiliza para el seguimiento de fusiones . Es un conjunto de cadenas de la forma file_name: revision_range . Aquí filename es el nombre completo (con la ruta desde la raíz del sistema de archivos del repositorio) del archivo o directorio desde el cual se fusionó el rango especificado de revisiones. Las filas se actualizan automáticamente durante las operaciones de combinación; en fusiones posteriores, Subversion tiene en cuenta las líneas añadidas previamente, evitando así la fusión repetida de los mismos cambios. No se recomienda cambiar la propiedad manualmente; esto puede romper el mecanismo de seguimiento de combinación.svn:mergeinfo Propiedades del directorio svn:ignore Una lista de patrones de nombres de archivos y directorios que el programa cliente de Subversion ignorará en este directorio. Esta propiedad es similar a un archivo .cvsignoreen CVS . Como regla general, la propiedad está configurada de tal manera que el programa cliente "no ve" archivos y directorios que son creados automáticamente por varios programas y no deben ser versionados (por ejemplo, archivos de objetos , archivos temporales , etc.). Esta propiedad no se aplica a los subdirectorios. svn:externals Le permite extraer automáticamente un conjunto de directorios en una copia de trabajo especificando su URL (incluso puede hacerlo desde otro repositorio). svn:mergeinfo Lo mismo que para los archivos . Propiedades de revisiónEl segundo tipo de objeto para el que existen propiedades son las propias revisiones. En este caso, los nombres de propiedad también pueden ser cualquier cosa; algunas propiedades con el prefijo "svn:" tienen un significado especial. La diferencia entre las propiedades de las revisiones y las propiedades de los objetos del sistema de archivos es que para las primeras, el concepto de historial de versiones no es aplicable (ya que se asigna un valor de propiedad específico a una revisión). En otras palabras, las propiedades de revisión se pueden cambiar, pero se pierde el valor anterior. De forma predeterminada, los cambios en las propiedades de revisión están deshabilitados; para permitir que el administrador cree un script ( eng. hook ) manejando el evento pre-revprop-change.
svn:date La fecha y hora en que se creó la revisión. svn:author El nombre del usuario que confirmó los cambios incluidos en esta revisión. svn:log Una descripción de los cambios confirmados en esta revisión (el texto ingresado por el usuario al confirmar los cambios).Como regla general, las propiedades de revisión solo las cambia el administrador del repositorio para corregir datos incorrectos. Por ejemplo, si el usuario olvidó proporcionar una descripción de texto al confirmar sus cambios, el administrador puede crear esta descripción editando el archivo svn:log.
Una iteración típica de flujo de trabajo con Subversion incluye los siguientes pasos.
La bifurcación es un aspecto importante de cómo funcionan los sistemas de control de versiones porque las técnicas típicas de control de versiones [47] (al menos en el desarrollo de software ) implican el uso de bifurcaciones. Subversion tiene capacidades de bifurcación y fusión bastante avanzadas (sin embargo , no admite la fusión de archivos y directorios renombrados).
En la fig. La Figura 3 muestra convencionalmente un ejemplo de la evolución de las ramas en el repositorio. El color verde muestra la línea principal de desarrollo del proyecto ( eng. mainline, trunk ), amarillo - ramas, azul - etiquetas, magenta - una rama cuyo desarrollo se ha interrumpido. Las flechas rojas muestran los cambios de fusión.
Creación de sucursalesEl comando crea una nueva rama (así como una etiquetasvn copy ) , que crea una copia en el repositorio con la herencia del historial de revisión de la fuente ( operación A+ ). Siempre debe usar la forma "remota" del comando para crear ramas svn copy, por ejemplo:
svn copy http://.../trunk/dir http://.../branches/branch_name -m "Creando una rama de dir"La copia resultante será una rama (o una etiqueta, dependiendo de cómo trabajes con ella). En el futuro, los cambios realizados en una rama se pueden realizar en la fuente a partir de la cual se creó esta rama; dicha propagación de cambios se denomina combinación .
Las operaciones de copia en Subversion son baratas ( es decir, copia barata ), es decir, requieren una pequeña cantidad fija de tiempo y espacio en disco. El almacenamiento está diseñado de tal manera [48] que durante cualquier copia, los datos no se duplican, sino que se crea un enlace a la fuente (similar a un enlace duro ); sin embargo, este mecanismo es puramente interno, desde el punto de vista del usuario. vista, es la creación de una copia que se produce. Gracias a la alta eficiencia de la bifurcación, se pueden crear ramas con la frecuencia necesaria (sin embargo , la fusión , una adición necesaria a la bifurcación, es más lenta en Subversion que en otros sistemas de control de versiones modernos).
Trabajando con ramasEn general, trabajar en una sucursal no es diferente de trabajar en la línea de desarrollo principal ( troncal ). Se requieren comandos específicos solo para actividades que involucran más de una rama. Estos comandos incluyen (además del comando crear rama svn copy):
Como regla general, el ciclo completo de trabajo con sucursales incluye los siguientes pasos:
Una fusión en Subversion es la aplicación a una rama de un conjunto de cambios realizados en otra (o la misma) rama. Para implementar una combinación, debe usar un comando svn merge : aplica un conjunto de cambios a una copia de trabajo; entonces necesita confirmar los cambios ( svn commit).
Combinar la terminología es algo confuso. El término fusión no es del todo exacto, ya que no hay fusión de ramas como tal . Además, no debe equiparar la combinación y el comando : en primer lugar, para la combinación debe realizar (además de ) la resolución de conflictos y la confirmación, y en segundo lugar, la aplicación no se limita a la combinación. svn mergesvn mergesvn merge
Otros usos del comando svn mergeEl comando svn mergese puede usar para algo más que fusionar. De hecho, el comando realiza cambios en la copia de trabajo iguales a la diferencia entre dos directorios o archivos en el repositorio , por lo que svn mergees una herramienta universal para transferir cambios. Aquí hay algunos ejemplos de cómo usar el comando svn merge:
El comando se utiliza para crear una bóveda svnadmin create. Esta operación creará una tienda vacía en el directorio especificado.
A continuación se muestra una comparación de los parámetros de los sistemas Subversion y CVS, ya que Subversion se posiciona precisamente como una mejora sobre CVS. Se hace una comparación solo para aquellos parámetros en los que estos sistemas difieren. En general, Subversion supera a CVS en todos los sentidos excepto en las etiquetas en el sentido convencional (es decir, etiquetas que se refieren a objetos del sistema de archivos).
| Parámetro | subversión | CVS |
|---|---|---|
| Capacidades | ||
| Catálogos | Realiza un seguimiento de las versiones no solo de los archivos, sino también de los directorios. | Las versiones del directorio no se rastrean, es decir, la estructura del directorio es la misma (la que existe en el repositorio en este momento) para todas las revisiones y todas las ramas. Si cambia la estructura de directorios, al extraer los estados antiguos, obtenemos las revisiones correctas (antiguas) de los archivos, pero en la estructura de directorios incorrecta (existente en el momento de la extracción). |
| Actas | Atomicidad de confirmaciones de varios archivos. | La atomicidad está solo al nivel de las confirmaciones de un solo archivo. En efecto, la confirmación de cambios en varios archivos se divide en una secuencia de confirmaciones en archivos individuales. Si se interrumpe una secuencia de confirmaciones de este tipo, algunos de los archivos permanecerán confirmados, mientras que otros permanecerán sin confirmar. |
| conjuntos de cambios | Los conjuntos de cambios son compatibles . | Los conjuntos de cambios no son compatibles. |
| Modificaciones de nombre de archivo | Admite copiar, mover y renombrar archivos y directorios sin perder el historial de cambios. | Al copiar, mover y renombrar archivos, el archivo con el nuevo nombre no tiene historial, es decir, se pierde por completo la conexión con el nombre anterior y su historial de versiones. Lo mismo para archivos dentro de un directorio al modificar su nombre [49] . |
| propiedades | Cada archivo y directorio puede tener un conjunto arbitrario de propiedades asociadas, que consisten en un nombre y un valor. Las propiedades también están bajo control de versiones. | Las propiedades no son compatibles. |
| Cerraduras | Se admite el bloqueo de archivos opcional (desde la versión 1.2). | No se admiten bloqueos, pero existe un mecanismo similar llamado seguimiento . |
| sucursales | Las ramas ( rama , ver Glosario ) se implementan en el espacio de ruta. Esto quiere decir que para crear una sucursal se copia el directorio (la copia será la sucursal). La creación de tales copias es una operación rápida y que no consume muchos recursos, porque los datos no se duplican , sino que se fija una nueva versión, que difiere de la anterior solo en la ubicación de los archivos. | Las ramas se implementan en la "tercera dimensión". Esto significa que un archivo en una rama se direcciona con tres parámetros: ruta en el sistema de archivos, revisión (o alguna otra forma de indicar la revisión, como la hora), nombre de la rama . |
| Etiquetas | No existen etiquetas ( tag , ver diccionario ) como tal. En su lugar, se utiliza una jerarquía de directorios: se crea un directorio separado para la etiqueta (así como para la rama). Una etiqueta es una rama en la que, por convención, no se realizan más cambios. Una etiqueta es una copia del estado etiquetado de archivos y directorios. | Las etiquetas son compatibles. La etiqueta aborda el estado etiquetado de los archivos. |
| Eficiencia | ||
| Intercambio cliente-servidor | Cualquier actualización de versión entre el cliente y el servidor solo transfiere las diferencias de archivos, lo que puede reducir significativamente el tráfico de red. | Las diferencias se transfieren del servidor al cliente y el objeto completo se transfiere del cliente al servidor. |
| binarios | Funciona con la misma eficacia con archivos de texto y binarios . | Trabajar con archivos binarios es menos eficiente: cada nueva versión se almacena en el repositorio en su totalidad. |
| Creación de ramas y etiquetas | Requiere una pequeña cantidad fija de tiempo y espacio en disco. | Los costos de tiempo son altos (dependiendo de la cantidad de archivos involucrados). Los nombres de ramas y etiquetas se almacenan de forma redundante (en todos los archivos involucrados). |
| Gastos generales en copia de trabajo | Los directorios de servicio de la copia de trabajo almacenan una copia limpia. Por lo tanto, navegar y revertir los cambios locales es rápido (sin ir al almacenamiento), pero el tamaño de la copia de trabajo en el disco es aproximadamente el doble del tamaño de los datos mismos. | No se almacena una copia limpia, el tamaño de la copia de trabajo es aproximadamente igual al tamaño de los datos. Como resultado, las operaciones de visualización y reversión de cambios locales requieren acceso al repositorio y son lentas. |
| Consumo de memoria en el servidor | Menos [50] . | Más. |
Hay un programa cvs2svn diseñado para convertir un repositorio CVS en un repositorio Subversion listo para usar (o un repositorio git ) o en un volcado de texto, que luego se puede importar al repositorio usando el archivo svnadmin. Al mismo tiempo, cvs2svn guarda toda la información contenida en el repositorio de CVS: ramas, etiquetas, descripciones de cambios, nombres de autores, fechas de confirmación. Además, los cambios en diferentes archivos comprometidos juntos se convierten en una sola revisión.
Diferencias en el uso Diferencias en el manejo de archivosEn CVS, mover (renombrar) y copiar archivos y directorios se realiza volviendo a agregar un objeto con un nuevo nombre y (al mover y renombrar) eliminando el objeto anterior. Con este trabajo, los archivos y directorios del repositorio se crean de nuevo y pierden su historial de cambios. Subversion debe usar los comandos mover ( moveo mv) y copiar ( copy) para realizar estas operaciones. Su uso conserva el historial de cambios y le permite evitar operaciones innecesarias (especialmente cuando se trata de directorios o incluso de ramas del sistema de archivos).
A diferencia de CVS, algunas operaciones de copia de trabajo (como eliminar y mover un archivo) son manejadas por Subversion. Las diferencias descritas y otras cuando se trabaja con archivos de copia de trabajo se resumen en la siguiente tabla ( commitse omite la operación , donde es necesaria en ambos casos):
| Operación | CVS | subversión | notas |
|---|---|---|---|
| Borrar un archivo | archivo rm archivo cvs rm |
svn rm file | el archivo no necesita ser borrado manualmente primero |
| Eliminación de archivos por máscara | rm * cvs rm archivo1 archivo2 ... |
svn rm * | los archivos no necesitan ser eliminados manualmente de antemano no es necesario enumerar todos los archivos |
| Renombrar/Mover | mv archivo1 archivo2 cvs rm archivo1 cvs agregar archivo2 |
svn mv file1 file2 | el archivo no necesita ser movido manualmente el historial del archivo se conserva |
| proceso de copiar | cp archivo1 archivo2 cvs agregar archivo2 |
svn copy file1 file2 | el archivo no necesita ser copiado manualmente el historial del archivo se conserva (bifurcado) |
| Agregar (crear) un directorio | mkdir directorio cvs agregar directorio |
svn mkdir dir svn confirmar |
el directorio no se puede crear manualmente después de agregar el directorio es necesariocommit |
| Agregar un directorio con archivos | cvs agregar dir cd dir cvs agregar archivo1 archivo2 |
svn add dir | se agrega el directorio con los archivos que contiene |
| Cambiar el nombre de un directorio con archivos (sin subdirectorios) |
mkdir dir2 cvs agregar dir2 mv dir1/* dir2 cvs rm dir1/archivo1 dir1/archivo2 ... cvs agregar dir2/* |
svn mv dir1 dir2 | no es necesario crear y agregar directorios no es necesario mover archivos manualmente no es necesario enumerar todos los archivos se guarda el historial de archivos |
| Cambiar el nombre de una rama del sistema de archivos (directorios con archivos y subdirectorios) |
repita los comandos anteriores para cada nivel de anidamiento o cada subdirectorio [51] |
svn mv dir1 dir2 | ver arriba no depende del número de niveles y directorios |
En Subversion, no es necesario crear etiquetas o usar una fecha/hora para abordar el estado del repositorio, en casos simples (por ejemplo, para obtener una versión después de un compromiso determinado), será más fácil especificar el número de revisión requerido .
Subversion está diseñado como un conjunto de bibliotecas divididas en varios niveles. Cada uno de ellos realiza una tarea específica y permite a los desarrolladores crear sus propias herramientas, según la complejidad y la tarea.
fs El nivel más bajo; implementa un sistema de archivos versionado que almacena datos. Repos El nivel de almacenamiento implementado en el sistema de archivos. En este nivel se implementan muchas funciones auxiliares, y también se soporta el lanzamiento de handlers (en inglés hooks ), es decir, scripts que se lanzan cuando ocurre un evento. Juntos, los niveles Fs y Repos conforman la interfaz del sistema de archivos . mod_dav_svn Proporciona acceso WebDAV / Delta-V a través de Apache 2. Real academia de bellas artes Implementa el acceso al almacenamiento (tanto local como remoto). A partir de este nivel, el repositorio puede ser referenciado por URL, es decir,La utilidad de cliente estándar de Subversion, SVN, se configura mediante variables de entorno y archivos INI creados en el directorio de inicio del usuario en un subdirectorio .subversion(la ubicación de la configuración en sistemas Windows, en archivos o en el registro, depende de la configuración del sistema). En la configuración, SVN también almacena en caché certificados SSL, inicios de sesión, contraseñas, etc. (a menos que esté deshabilitado en la configuración) para acceder a los servidores de Subversion.
Contenido del directorio .subversion:
Es posible que Subversion no siempre maneje los cambios de nombre de archivo correctamente si el contenido del archivo se cambia al mismo tiempo que el cambio de nombre. También pueden surgir problemas si un archivo renombrado en la copia local es modificado por otra persona en el repositorio. Algunos de estos problemas se corrigieron en la versión 1.5, pero esta solución aún no está completa. [53]
Las operaciones de fusión de sucursales también se consideran un punto débil de Subversion. Antes de la versión 1.5, los usuarios tenían que realizar un seguimiento manual de todas esas operaciones utilizando entradas detalladas del registro de cambios. Desde la versión 1.5, se ha introducido soporte básico para el seguimiento automático de fusiones, que los desarrolladores planean mejorar en versiones posteriores [54] . Subversion actualmente admite escenarios de fusión comunes bastante bien; en casos más complejos, los problemas son posibles. Se recomienda [55] organizar el flujo de trabajo de forma que se eviten escenarios problemáticos. No se admite la combinación de archivos y directorios renombrados.
La información una vez colocada en el repositorio de Subversion permanece allí para siempre: un archivo se puede eliminar en la revisión actual, pero siempre es posible recuperar del repositorio una de las revisiones anteriores en las que existía el archivo. Aunque mantener las revisiones pasadas es en realidad el propósito de usar los sistemas de control de versiones, a veces es necesario eliminar por completo la información de un repositorio que se colocó allí por error. Subversion no proporciona ninguna forma nativa de hacer esto [56] ; la única posibilidad es crear un volcado de almacenamiento, procesarlo con la utilidad svndumpfilter estándar y luego restaurar el almacenamiento desde el volcado. También existen programas de terceros para automatizar este proceso, pero en cualquier caso, esta operación requiere una suspensión temporal del acceso al almacenamiento y la intervención de un administrador con privilegios lo suficientemente altos como para borrar completamente el antiguo almacenamiento y reemplazarlo por uno nuevo. una.
|
Nombre |
Descripción |
Idioma |
base de datos |
Licencia |
Sitio web |
Actualizar |
Versión |
|
una herramienta basada en tecnología Wiki |
Pitón |
SQLite, PostgreSQL, MySQL y MariaDB |
trac.edgewall.org Archivado el 8 de abril de 2013 en Wayback Machine . |
21/06/2017 |
1.2.2 | ||
|
seguimiento de errores adicional |
rubí |
MySQL, PostgreSQL, SQLite, Oracle. |
redmine.org Archivado el 27 de abril de 2011 en Wayback Machine . |
09.12.2018 |
4.0.0 | ||
|
utilidad para crear y administrar el acceso a repositorios, especializada para SVN |
PHP |
MySQL, SQLite |
CeCill (licencia compatible con GPL). |
www.usvn.info Archivado el 12 de mayo de 2011 en Wayback Machine . |
13/01/2012 |
1.0.6 | |
|
VerVC |
sin gestión de usuarios, no requiere soporte DAV por parte del servidor web. |
Pitón |
mysql |
Estilo Berkeley de dos cláusulas |
www.viewvc.org Archivado el 4 de mayo de 2011 en Wayback Machine . |
02.12.2010 |
1.1.8 |
|
WebSVN |
interfaz de navegación para SVN |
PHP |
XML |
websvn.tigris.org Archivado el 12 de junio de 2006 en Wayback Machine . |
10/12/2010 |
2.3.2 | |
|
utilidad para gestionar repositorios (crear, borrar, cargar y descargar; gestionar usuarios y grupos) |
PHP |
MySQL o SQLite |
svnmanager.sourceforge.net Archivado el 30 de abril de 2011 en Wayback Machine . |
28/01/2012 |
1.09 | ||
|
Submin (MIT) |
utilidad para administrar repositorios y usuarios, incluida la administración del control de acceso para directorios individuales en un repositorio |
Pitón |
MIT/X Archivado el 6 de junio de 2011 en Wayback Machine . |
24.12.2012 |
2.1 | ||
|
cSvN |
interfaz web para ver los repositorios de Subversion |
C |
csvn.radix.pro Archivado el 16 de marzo de 2022 en Wayback Machine . |
17/11/2020 |
0.1.3 |
| Sistemas de control de versiones ( categoría ) | |
|---|---|
| Solo locales | |
| Servidor de cliente | |
| Repartido | |
| esquemas URI | |
|---|---|
| Oficial | |
| no oficial | |