Control de versiones

En términos de teoría de grafos , las revisiones se suelen concebir como una línea de desarrollo (el tronco ) con ramificaciones que se desprenden de ella, formando un árbol dirigido, visualizado como una o más líneas de desarrollo paralelas (las ramas principales) que se ramifican desde un tronco. En realidad, la estructura es más compleja, formando un grafo dirigido acíclico , pero para muchos propósitos, "árbol con fusiones" es una aproximación adecuada.

Las revisiones ocurren en secuencia a lo largo del tiempo y, por lo tanto, pueden ordenarse, ya sea por número de revisión o marca de tiempo. ^{[ nota 2 ]} Las revisiones se basan en revisiones anteriores, aunque es posible reemplazar en gran medida o por completo una revisión anterior, como "eliminar todo el texto existente, insertar texto nuevo". En el caso más simple, sin ramificaciones ni deshacer, cada revisión se basa únicamente en su predecesor inmediato y forman una línea simple, con una única versión más reciente, la revisión "HEAD" o punta . En términos de teoría de grafos , al dibujar cada revisión como un punto y cada relación de "revisión derivada" como una flecha (que convencionalmente apunta de la más antigua a la más reciente, en la misma dirección que el tiempo), se trata de un grafo lineal . Si hay ramificaciones, de modo que múltiples revisiones futuras se basan en una revisión anterior, o deshacer, de modo que una revisión puede depender de una revisión anterior a su predecesor inmediato, entonces el grafo resultante es un árbol dirigido (cada nodo puede tener más de un hijo) y tiene múltiples puntas, que corresponden a las revisiones sin hijos ("última revisión en cada rama"). ^{[ nota 3 ]} En principio, el árbol resultante no necesita tener una punta preferida ("principal" última revisión), sino varias revisiones diferentes; pero en la práctica, una punta generalmente se identifica como HEAD. Cuando una nueva revisión se basa en HEAD, se identifica como el nuevo HEAD o se considera una nueva rama. ^{[ nota 4 ]} La lista de revisiones desde el inicio hasta HEAD (en términos de teoría de grafos, la ruta única en el árbol, que forma un grafo lineal como antes) es el tronco o línea principal. ^{[ nota 5 ]} Por el contrario, cuando una revisión puede basarse en más de una revisión anterior (cuando un nodo puede tener más de un padre ), el proceso resultante se llama fusión y es uno de los aspectos más complejos del control de revisiones. Esto ocurre con mayor frecuencia cuando se producen cambios en múltiples ramas (generalmente dos, pero es posible que haya más), que luego se fusionan en una sola rama que incorpora ambos cambios. Si estos cambios se superponen, puede ser difícil o imposible fusionarlos y requerir intervención manual o reescritura.

En presencia de fusiones, el grafo resultante ya no es un árbol, puesto que los nodos pueden tener múltiples padres, sino un grafo acíclico dirigido (DAG) con raíz. El grafo es acíclico porque los padres siempre están en orden cronológico inverso, y tiene raíz porque existe una versión más antigua. Suponiendo que existe un tronco, las fusiones de las ramas pueden considerarse "externas" al árbol: los cambios en la rama se empaquetan como un parche, que se aplica a HEAD (del tronco), creando una nueva revisión sin ninguna referencia explícita a la rama y preservando la estructura del árbol. Por lo tanto, aunque las relaciones reales entre versiones forman un DAG, esto puede considerarse un árbol más fusiones, y el tronco en sí es una línea.

En el control de versiones distribuido, cuando existen varios repositorios, estos pueden basarse en una única versión original (la raíz del árbol), pero no es necesario que exista una raíz original; en su lugar, puede haber una raíz independiente (la revisión más antigua) para cada repositorio. Esto puede ocurrir, por ejemplo, si dos personas comienzan a trabajar en un proyecto por separado. Del mismo modo, cuando existen varios conjuntos de datos (varios proyectos) que intercambian datos o se fusionan, no hay una única raíz, aunque, para simplificar, se puede considerar un proyecto como principal y el otro como secundario, fusionado con el primero con o sin su propio historial de revisiones.

El control de versiones está muy extendido en el ámbito empresarial y jurídico. De hecho, las "revisiones de contratos" y las "revisiones legales" son algunas de las primeras formas de control de revisiones ^{[ 10 ]} y todavía se emplean en ambos ámbitos con distintos grados de sofisticación. Las técnicas más sofisticadas están empezando a utilizarse para el seguimiento electrónico de los cambios en los archivos CAD (véase la gestión de datos de producto ), sustituyendo la implementación electrónica "manual" del control de revisiones tradicional ^{[ 11 ] .}

El desarrollo de videojuegos suele implicar archivos binarios de gran tamaño y equipos que trabajan juntos en diferentes disciplinas. Por ello, los estudios de videojuegos utilizan sistemas de control de versiones con buen soporte para archivos binarios grandes, bloqueo de archivos y sincronización rápida. Entre las herramientas más comunes se encuentran Perforce y varios sistemas más recientes basados ​​en la nube. ^{[ 12 ] [ 13 ]}

Una operación es atómica si el sistema permanece en un estado consistente incluso si la operación se interrumpe. La operación de confirmación suele ser la más crítica en este sentido. Las confirmaciones le indican al sistema de control de versiones que haga que un grupo de cambios sea definitivo y esté disponible para todos los usuarios. No todos los sistemas de control de versiones tienen confirmaciones atómicas; el Sistema de Versiones Concurrentes carece de esta característica. ^{[ 14 ]}

El método más sencillo para prevenir problemas de acceso concurrente consiste en bloquear los archivos de forma que solo un desarrollador a la vez tenga acceso de escritura a las copias centrales del repositorio . Una vez que un desarrollador extrae un archivo, los demás pueden leerlo, pero nadie más puede modificarlo hasta que ese desarrollador registre la versión actualizada (o cancele la extracción).

El bloqueo de archivos tiene ventajas y desventajas. Puede ofrecer cierta protección contra conflictos de fusión complejos cuando un usuario realiza cambios radicales en varias secciones de un archivo grande (o grupo de archivos). Si los archivos permanecen bloqueados exclusivamente durante demasiado tiempo, otros desarrolladores podrían verse tentados a eludir el software de control de versiones y modificarlos localmente, lo que obligaría a una fusión manual complicada cuando finalmente se confirmen los demás cambios. En una organización grande, los archivos pueden quedar bloqueados y olvidados mientras los desarrolladores cambian de proyecto; estas herramientas pueden o no facilitar la identificación de quién tiene un archivo bloqueado.

La mayoría de los sistemas de control de versiones permiten que varios desarrolladores editen el mismo archivo simultáneamente. El primer desarrollador que confirme los cambios en el repositorio central siempre tendrá éxito. El sistema puede ofrecer funciones para integrar los cambios posteriores en el repositorio central y conservar los cambios del primer desarrollador cuando otros desarrolladores confirmen los suyos.

Combinar dos archivos puede ser una operación muy delicada, y generalmente solo es posible si la estructura de datos es simple, como en los archivos de texto . El resultado de combinar dos archivos de imagen podría no ser un archivo de imagen. El segundo desarrollador que revise los archivos deberá tener cuidado con la combinación para asegurarse de que los cambios sean compatibles y que la operación de combinación no introduzca errores lógicos en los archivos. Estos problemas limitan la disponibilidad de operaciones de combinación automáticas o semiautomáticas principalmente a documentos de texto simples, a menos que exista un complemento de combinación específico para los tipos de archivo.

El concepto de edición reservada puede proporcionar un medio opcional para bloquear explícitamente un archivo para un acceso de escritura exclusivo, incluso cuando existe la capacidad de fusión.

La mayoría de las herramientas de control de versiones utilizan solo uno de estos términos similares (línea base, etiqueta, rótulo) para referirse a la acción de identificar una instantánea ("etiquetar el proyecto") o al registro de la instantánea ("inténtalo con la línea base X "). Normalmente, solo se utiliza uno de los términos línea base , etiqueta o rótulo en la documentación o en las discusiones ^{[ 15 ]}  ; pueden considerarse sinónimos.

En la mayoría de los proyectos, algunas instantáneas son más importantes que otras, como por ejemplo las que se utilizan para indicar versiones publicadas, ramas o hitos.

Cuando se utilizan juntos los términos " línea base" y " etiqueta " o "rótulo" en el mismo contexto, "etiqueta" y "rótulo" suelen referirse al mecanismo dentro de la herramienta para identificar o registrar la instantánea, y " línea base" indica la mayor importancia de cualquier etiqueta o rótulo determinado.

La mayoría de las discusiones formales sobre la gestión de la configuración utilizan el término línea base .

Además del coste de la licencia del software de control de versiones, su uso requiere tiempo y esfuerzo. Es necesario comprender los conceptos subyacentes y aprender los detalles técnicos necesarios para operar el software elegido. Asimismo, se deben aprender las mejores prácticas de control de versiones e integrarlas en las prácticas de desarrollo de software existentes en la organización. Puede ser necesario un esfuerzo por parte de la dirección para mantener la disciplina necesaria para seguir las mejores prácticas y obtener así un beneficio real.

A menudo hay plugins disponibles para IDE como Oracle JDeveloper , IntelliJ IDEA , Eclipse , Visual Studio , Delphi , NetBeans IDE , Xcode y GNU Emacs (a través de vc.el). Los prototipos de investigación avanzada generan mensajes de confirmación apropiados. ^{[ 26 ]}

Una revisión aprobada de un documento o archivo fuente a la que se pueden realizar cambios posteriores. Véase líneas base, etiquetas y rótulos .

Una búsqueda del autor y la revisión que modificó por última vez una línea en particular.

Un conjunto de archivos bajo control de versiones puede ramificarse o bifurcarse en un momento dado, de modo que, a partir de ese momento, dos copias de esos archivos puedan desarrollarse a velocidades diferentes o de maneras diferentes, independientemente una de la otra.

Un cambio (o diff , o delta ) representa una modificación específica de un documento bajo control de versiones. El grado de detalle de la modificación considerada como un cambio varía entre los sistemas de control de versiones.

En muchos sistemas de control de versiones con confirmaciones atómicas de múltiples cambios, una lista de cambios (o CL ), un conjunto de cambios , una actualización o un parche identifica el conjunto de cambios realizados en una sola confirmación. Esto también puede representar una vista secuencial del código fuente, lo que permite examinar el código fuente a partir de cualquier ID de lista de cambios específico.

Extraer un archivo (o copiarlo ) significa crear una copia de trabajo local desde el repositorio. Un usuario puede especificar una revisión concreta u obtener la más reciente. El término «extraer» también se usa como sustantivo para describir la copia de trabajo. Cuando un archivo se ha extraído de un servidor de archivos compartido, otros usuarios no pueden editarlo. Es como en un hotel: al salir, ya no se tiene acceso a sus servicios.

Clonar significa crear un repositorio que contenga las revisiones de otro repositorio. Esto equivale a enviar o recibir cambios a un repositorio vacío (recién inicializado). Dos repositorios se consideran clones si se mantienen sincronizados y contienen las mismas revisiones.

Confirmar ( o , más raramente, instalar , enviar o registrar ) significa escribir o fusionar los cambios realizados en la copia de trabajo en el repositorio. Una confirmación contiene metadatos, normalmente la información del autor y un mensaje que describe el cambio.

Una breve nota, escrita por el desarrollador y almacenada junto con la confirmación, que describe dicha confirmación. Idealmente, registra el motivo de la modificación, una descripción de su efecto o propósito, y aspectos menos evidentes de su funcionamiento.

Se produce un conflicto cuando distintas partes modifican el mismo documento y el sistema no puede conciliar dichos cambios. El usuario debe resolver el conflicto combinando las modificaciones o seleccionando una en lugar de la otra.

La mayoría del software de control de versiones utiliza compresión delta , que conserva únicamente las diferencias entre versiones sucesivas de los archivos. Esto permite un almacenamiento más eficiente de muchas versiones diferentes de archivos.

Una secuencia en la que algunas o todas las versiones de los archivos son réplicas exactas de las versiones de la secuencia principal.

Exportar consiste en obtener los archivos del repositorio. Es similar a extraerlos, con la diferencia de que crea una estructura de directorios limpia, sin los metadatos de control de versiones que se utilizan en una copia de trabajo. Esto se suele usar, por ejemplo, antes de publicar el contenido.

Ver tirar .

El proceso de integrar los cambios realizados en la rama principal en una rama de desarrollo (de funcionalidad o de equipo).

También llamado a veces punta , se refiere a la confirmación más reciente, ya sea en el tronco o en una rama. El tronco y cada rama tienen su propia cabeza, aunque HEAD a veces se usa de forma imprecisa para referirse al tronco. ^{[ 33 ]}

La importación consiste en copiar por primera vez un árbol de directorios local (que actualmente no es una copia de trabajo) en el repositorio.

Para crear un repositorio nuevo y vacío.

Algunos programas de control de versiones utilizan deltas intercalados , un método que permite almacenar el historial de archivos de texto de una manera más eficiente que mediante la compresión delta .

Ver etiqueta .

Cuando un desarrollador bloquea un archivo, nadie más puede actualizarlo hasta que se desbloquee. El bloqueo puede realizarse mediante el sistema de control de versiones o a través de comunicaciones informales entre desarrolladores (lo que se conoce como bloqueo social ).

Similar a trunk , pero puede haber una rama principal para cada rama secundaria.

Una fusión o integración es una operación en la que se aplican dos conjuntos de cambios a un archivo o conjunto de archivos. Algunos ejemplos de escenarios son los siguientes:

• Un usuario, que trabaja en un conjunto de archivos, actualiza o sincroniza su copia de trabajo con los cambios realizados y registrados en el repositorio por otros usuarios. ^{[ 34 ]}
• Un usuario intenta registrar archivos que han sido actualizados por otros desde que se extrajeron , y el software de control de versiones fusiona automáticamente los archivos (normalmente, después de preguntar al usuario si debe proceder con la fusión automática, y en algunos casos solo lo hace si la fusión se puede resolver de forma clara y razonable).
• Se crea una rama , se edita de forma independiente el código de los archivos y, posteriormente, la rama actualizada se incorpora a un único tronco unificado .
• Se crea una bifurcación a partir de un conjunto de archivos , se corrige un problema preexistente en una rama y, posteriormente, la corrección se integra en la otra rama. (Este tipo de fusión selectiva se conoce a veces como " cherry pick" para distinguirla de la fusión completa del caso anterior).

El acto de copiar el contenido de un archivo desde una ubicación menos controlada a una ubicación más controlada. Por ejemplo, desde el espacio de trabajo de un usuario a un repositorio, o desde un flujo a su padre. ^{[ 35 ]}

Copiar revisiones de un repositorio a otro. La operación pull la inicia el repositorio receptor, mientras que la operación push la inicia el repositorio de origen. A veces, fetch se usa como sinónimo de pull , o para referirse a una operación pull seguida de una actualización .

El acto de intervención del usuario para resolver un conflicto entre diferentes cambios realizados en el mismo documento.

El proceso de fusionar diferentes ramas de equipo en el tronco principal del sistema de control de versiones.

El abandono de uno o más cambios recientes en favor de volver a una versión anterior del material en cuestión. Una reversión puede realizarse por muchas razones, entre ellas: corregir errores introducidos por ediciones anteriores; restaurar el material a un estado que no era controvertido hasta que se puedan resolver nuevas disputas; revertir la ampliación del alcance ; y realizar pruebas de regresión .

Una versión es cualquier cambio de forma. En SVK, una revisión es el estado en un momento dado de todo el árbol en el repositorio.

El acto de hacer que un archivo o carpeta esté disponible en varias ramas simultáneamente. Cuando se modifica un archivo compartido en una rama, se modifica también en las demás.

Un contenedor para archivos ramificados que mantiene una relación conocida con otros contenedores similares. Los flujos forman una jerarquía; cada flujo puede heredar diversas propiedades (como versiones, espacio de nombres, reglas de flujo de trabajo, suscriptores, etc.) de su flujo principal.

Una etiqueta o rótulo se refiere a una instantánea importante en el tiempo, consistente en muchos archivos. En ese momento, todos estos archivos pueden estar etiquetados con un nombre o número de revisión descriptivo y fácil de usar. Consulte líneas base, etiquetas y rótulos .

El tronco es la única línea de desarrollo que no es una rama (a veces también llamada Línea base, Línea principal o Maestra ^{[ 42 ] [ 43 ]} ).

Una actualización (o sincronización , aunque sincronización también puede referirse a una combinación de envío y recepción ) fusiona los cambios realizados en el repositorio (por otras personas, por ejemplo) con la copia de trabajo local . Actualización es también el término utilizado por algunas herramientas de gestión de configuración (CM+, PLS, SMS) para el concepto de paquete de cambios (véase lista de cambios ). Sinónimo de extracción en sistemas de control de versiones que requieren que cada repositorio tenga exactamente una copia de trabajo (común en sistemas distribuidos).

Liberar un candado.

La copia de trabajo es la copia local de los archivos de un repositorio, en un momento o revisión específicos. Todo el trabajo realizado en los archivos de un repositorio se realiza inicialmente en una copia de trabajo, de ahí su nombre. Conceptualmente, es un entorno aislado (sandbox) .