Este artículo necesita citas adicionales para su verificación . ( abril de 2011 ) |
En ingeniería de software , el control de versiones (también conocido como control de revisión , control de fuente o administración de código fuente ) es una clase de sistemas responsables de administrar cambios en programas de computadora , documentos, sitios web grandes u otras colecciones de información. El control de versiones es un componente de la gestión de la configuración del software . [1]
Los cambios generalmente se identifican mediante un código de número o letra, denominado "número de revisión", "nivel de revisión" o simplemente "revisión". Por ejemplo, un conjunto inicial de archivos es "revisión 1". Cuando se realiza el primer cambio, el conjunto resultante es "revisión 2", y así sucesivamente. Cada revisión está asociada con una marca de tiempo y la persona que realiza el cambio. Las revisiones se pueden comparar, restaurar y fusionar con algunos tipos de archivos.
La necesidad de una forma lógica de organizar y controlar las revisiones ha existido durante casi todo el tiempo que ha existido la escritura , pero el control de revisiones se volvió mucho más importante y complicado cuando comenzó la era de la informática. La numeración de las ediciones de libros y las revisiones de las especificaciones son ejemplos que se remontan a la era de la impresión únicamente. Hoy en día, los sistemas de control de revisiones más capaces (además de complejos) son los que se utilizan en el desarrollo de software , donde un equipo de personas puede realizar cambios simultáneamente en los mismos archivos.
Los sistemas de control de versiones ( VCS ) se ejecutan más comúnmente como aplicaciones independientes, pero el control de revisiones también está integrado en varios tipos de software, como procesadores de texto y hojas de cálculo , documentos web colaborativos [2] y en varios sistemas de administración de contenido , por ejemplo, Wikipedia. historial de la página . El control de revisión permite la capacidad de revertir un documento a una revisión anterior, lo cual es fundamental para permitir que los editores rastreen las ediciones de los demás, corrijan errores y se defiendan contra el vandalismo y el spam en wikis .
En la ingeniería de software de computadora , el control de revisiones es cualquier tipo de práctica que rastrea y proporciona control sobre los cambios en el código fuente . Los desarrolladores de software a veces utilizan software de control de revisiones para mantener la documentación y los archivos de configuración , así como el código fuente.
A medida que los equipos diseñan, desarrollan e implementan software, es común que se implementen múltiples versiones del mismo software en diferentes sitios y que los desarrolladores del software trabajen simultáneamente en las actualizaciones. Los errores o características del software a menudo solo están presentes en ciertas versiones (debido a la solución de algunos problemas y la introducción de otros a medida que se desarrolla el programa). Por lo tanto, con el fin de localizar y corregir errores, es de vital importancia poder recuperar y ejecutar diferentes versiones del software para determinar en qué versión se produce el problema. También puede ser necesario desarrollar dos versiones del software al mismo tiempo: por ejemplo, cuando una versión tiene errores corregidos, pero no nuevas características ( rama), mientras que en la otra versión es donde se trabajan las nuevas funciones ( troncal ).
En el nivel más simple, los desarrolladores podrían simplemente retener múltiples copias de las diferentes versiones del programa y etiquetarlas apropiadamente. Este sencillo enfoque se ha utilizado en muchos grandes proyectos de software. Si bien este método puede funcionar, es ineficaz ya que se deben mantener muchas copias casi idénticas del programa. Esto requiere mucha autodisciplina por parte de los desarrolladores y, a menudo, conduce a errores. Dado que la base del código es la misma, también requiere otorgar permisos de lectura, escritura y ejecución a un conjunto de desarrolladores, y esto agrega la presión de alguien que administra los permisos para que la base del código no se vea comprometida, lo que agrega más complejidad. En consecuencia, se han desarrollado sistemas para automatizar parte o la totalidad del proceso de control de revisiones. Esto asegura que la mayor parte de la gestión de los pasos de control de versiones esté oculta entre bastidores.
Además, en el desarrollo de software, la práctica legal y comercial y otros entornos, se ha vuelto cada vez más común que un solo documento o fragmento de código sea editado por un equipo, cuyos miembros pueden estar geográficamente dispersos y pueden perseguir diferentes e incluso contrarios intereses. El control de revisión sofisticado que rastrea y da cuenta de la propiedad de los cambios en los documentos y el código puede ser extremadamente útil o incluso indispensable en tales situaciones.
El control de revisión también puede rastrear los cambios en los archivos de configuración , como los que normalmente se almacenan en /etc
o /usr/local/etc
sobre sistemas Unix. Esto ofrece a los administradores del sistema otra forma de realizar un seguimiento fácil de los cambios realizados y una forma de volver a versiones anteriores en caso de que surja la necesidad.
La herramienta de actualización de software OS / 360 IEBUPDTE de IBM se remonta a 1962, posiblemente un precursor de las herramientas VCS. En 1972 se inició un sistema completo diseñado para el control del código fuente, SCCS para el mismo sistema (OS / 360). La introducción de SCCS, que se publicó el 4 de diciembre de 1975, implicaba históricamente que era el primer sistema de control de revisiones deliberado. [3] RCS siguió justo después, [4] con su versión en red CVS. La siguiente generación después de CVS estuvo dominada por Subversion , [5] seguida por el surgimiento de herramientas distribuidas de control de revisiones como Git . [6]
El control de revisión gestiona los cambios en un conjunto de datos a lo largo del tiempo. Estos cambios se pueden estructurar de varias formas.
A menudo, los datos se consideran una colección de muchos elementos individuales, como archivos o documentos, y se realiza un seguimiento de los cambios en archivos individuales. Esto concuerda con las intuiciones sobre archivos separados, pero causa problemas cuando cambia la identidad, como al cambiar el nombre, dividir o fusionar archivos. En consecuencia, algunos sistemas como Git , en cambio, consideran los cambios en los datos como un todo, lo que es menos intuitivo para cambios simples pero simplifica los cambios más complejos.
Cuando los datos que están bajo control de revisión se modifican, después de ser recuperados mediante el check-out, esto no se refleja en general inmediatamente en el sistema de control de revisiones (en el repositorio ), sino que deben ser ingresados o confirmados. Una copia fuera del control de revisión se conoce como "copia de trabajo". Como ejemplo simple, al editar un archivo de computadora, los datos almacenados en la memoria por el programa de edición son la copia de trabajo, que se confirma al guardar. Concretamente, uno puede imprimir un documento, editarlo a mano y solo más tarde ingresar manualmente los cambios en una computadora y guardarlo. Para el control del código fuente, la copia de trabajo es en cambio una copia de todos los archivos en una revisión particular, generalmente almacenados localmente en la computadora del desarrollador;[nota 1] en este caso, guardar el archivo solo cambia la copia de trabajo, y el registro en el repositorio es un paso separado.
Si varias personas están trabajando en un solo conjunto de datos o documento, están creando implícitamente ramas de los datos (en sus copias de trabajo) y, por lo tanto, surgen problemas de fusión, como se analiza a continuación. Para una simple edición colaborativa de documentos, esto puede evitarse mediante el bloqueo de archivos o simplemente evitando trabajar en el mismo documento en el que está trabajando otra persona.
Los sistemas de control de revisiones a menudo están centralizados, con un único almacén de datos autorizado, el repositorio, y las salidas y comprobaciones se realizan con referencia a este repositorio central. Alternativamente, en el control de revisión distribuido , ningún repositorio tiene autoridad y los datos se pueden extraer y registrar en cualquier repositorio. Cuando se registra en un repositorio diferente, esto se interpreta como una combinación o parche.
En términos de la teoría de grafos , las revisiones generalmente se consideran una línea de desarrollo (el tronco ) con ramas fuera de este, formando un árbol dirigido, visualizado como una o más líneas paralelas de desarrollo (las "líneas principales" de las ramas) ramificándose de un baúl. En realidad, la estructura es más complicada, formando un gráfico acíclico dirigido , 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, se pueden organizar en orden, ya sea por número de revisión o por marca de tiempo. [nota 2] Las revisiones se basan en revisiones anteriores, aunque es posible reemplazar en gran parte 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 o sugerencia "HEAD" . En términos de teoría de grafos , dibujando cada revisión como un punto y cada relación de "revisión derivada" como una flecha (convencionalmente apuntando de más antigua a más nueva, en la misma dirección que el tiempo), este es un gráfico lineal.. Si hay ramificaciones, por lo que varias revisiones futuras se basan en una revisión anterior, o deshacer, por lo que una revisión puede depender de una revisión anterior a su predecesor inmediato, entonces el gráfico resultante es, en cambio, un árbol dirigido (cada nodo puede tener más de una child), y tiene varios consejos, correspondientes a las revisiones sin hijos ("última revisión en cada rama"). [nota 3] En principio, el árbol resultante no necesita tener una sugerencia preferida (la última revisión "principal"), solo varias revisiones diferentes, pero en la práctica, una sugerencia generalmente se identifica como HEAD. Cuando una nueva revisión se basa en HEAD, se identifica como la nueva HEAD o se considera una nueva rama. [nota 4]La lista de revisiones desde el principio hasta HEAD (en términos de teoría de grafos, la ruta única en el árbol, que forma un gráfico lineal como antes) es el tronco o la línea principal. [nota 5] A la inversa, cuando una revisión puede basarse en más de una revisión anterior (cuando un nodo puede tener más de una matriz ), el proceso resultante se llama una combinación , y es uno de los aspectos más complejos de control de revisión. Esto ocurre con mayor frecuencia cuando se producen cambios en varias ramas (la mayoría de las veces dos, pero es posible que haya más), que luego se fusionan en una única rama que incorpora ambos cambios. Si estos cambios se superponen, puede ser difícil o imposible fusionar y requerir intervención manual o reescritura.
En presencia de fusiones, el gráfico resultante ya no es un árbol, ya que los nodos pueden tener múltiples padres, sino que es un gráfico acíclico dirigido (DAG) enraizado . El gráfico es acíclico ya que los padres siempre están al revés en el tiempo y están arraigados porque hay una versión más antigua. Sin embargo, asumiendo que hay un tronco, las fusiones de ramas se pueden considerar como "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 conservando la estructura del árbol. Por lo tanto, si bien las relaciones reales entre las 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 revisión distribuido, en presencia de varios repositorios, estos pueden basarse en una única versión original (una raíz del árbol), pero no es necesario que haya una raíz original y, por lo tanto, solo una raíz separada (revisión más antigua) para cada repositorio. , por ejemplo, si dos personas comienzan a trabajar en un proyecto por separado. De manera similar, en presencia de múltiples conjuntos de datos (múltiples proyectos) que intercambian datos o se fusionan, no hay una sola raíz, aunque para simplificar uno puede pensar en un proyecto como primario y el otro como secundario, fusionado en el primero con o sin su propio historial de revisiones.
Control de revisión de ingeniería desarrollado a partir de procesos formalizados basados en el seguimiento de revisiones de los primeros planos o líneas azules [ cita requerida ] . Este sistema de control permitió implícitamente volver a un estado anterior del diseño, para los casos en los que se llegó a un callejón sin salida de ingeniería en el desarrollo del diseño. Se utilizó una tabla de revisión para realizar un seguimiento de los cambios realizados. Además, las áreas modificadas del dibujo se resaltaron usando nubes de revisión.
El control de versiones está muy extendido en los negocios y el derecho. De hecho, la "línea roja del contrato" y la "línea negra legal" son algunas de las formas más tempranas de control de revisión, [7] y todavía se emplean en los negocios y el derecho con diversos grados de sofisticación. Se están comenzando a utilizar las técnicas más sofisticadas para el seguimiento electrónico de cambios en archivos CAD (ver gestión de datos de productos ), reemplazando la implementación electrónica "manual" del control de revisión tradicional. [ cita requerida ]
Los sistemas de control de revisiones tradicionales utilizan un modelo centralizado en el que todas las funciones de control de revisiones tienen lugar en un servidor compartido . Si dos desarrolladores intentan cambiar el mismo archivo al mismo tiempo, sin algún método para administrar el acceso, los desarrolladores pueden terminar sobrescribiendo el trabajo del otro. Los sistemas de control de revisión centralizados resuelven este problema en uno de dos "modelos de administración de fuentes" diferentes: bloqueo de archivos y combinación de versiones.
Una operación es atómica si el sistema se deja en un estado consistente incluso si se interrumpe la operación. La operación de confirmación suele ser la más crítica en este sentido. Los compromisos le dicen al sistema de control de revisiones que haga un grupo de cambios definitivo y esté disponible para todos los usuarios. No todos los sistemas de control de revisiones tienen confirmaciones atómicas; en particular, CVS carece de esta característica. [8]
El método más simple de prevenir problemas de " acceso concurrente " implica bloquear archivos para que sólo un desarrollador a la vez tenga acceso de escritura a las copias del "repositorio" central de esos archivos. Una vez que un desarrollador "comprueba" un archivo, otros pueden leer ese archivo, pero nadie más puede cambiar ese archivo hasta que ese desarrollador "compruebe" la versión actualizada (o cancele la comprobación).
El bloqueo de archivos tiene tanto méritos como inconvenientes. Puede proporcionar cierta protección contra conflictos de fusión difíciles cuando un usuario realiza cambios radicales en muchas secciones de un archivo grande (o grupo de archivos). Sin embargo, si los archivos se dejan bloqueados exclusivamente durante demasiado tiempo, otros desarrolladores pueden tener la tentación de omitir el software de control de revisiones y cambiar los archivos localmente, lo que obliga a una combinación manual difícil cuando finalmente se registran los otros cambios. En una organización grande, los archivos se puede dejar "desprotegido" y bloqueado y olvidado a medida que los desarrolladores se mueven entre proyectos; estas herramientas pueden facilitar o no ver quién tiene un archivo desprotegido.
La mayoría de los sistemas de control de versiones permiten que varios desarrolladores editen el mismo archivo al mismo tiempo. El primer desarrollador que "registra" los cambios en el repositorio central siempre tiene éxito. El sistema puede proporcionar facilidades para fusionar más cambios en el repositorio central y preservar los cambios del primer desarrollador cuando otros desarrolladores se registran.
Combinar dos archivos puede ser una operación muy delicada y, por lo general, solo es posible si la estructura de datos es simple, como en los archivos de texto . Es posible que el resultado de una combinación de dos archivos de imagen no genere un archivo de imagen. El segundo desarrollador que verifique el código deberá tener cuidado con la fusión, para asegurarse de que los cambios sean compatibles y que la operación de fusión no introduzca sus propios errores lógicos dentro de los archivos. Estos problemas limitan la disponibilidad de operaciones de combinación automáticas o semiautomáticas principalmente a documentos simples basados en texto, a menos que haya un complemento de combinación específico disponible para los tipos de archivo.
El concepto de edición reservada puede proporcionar un medio opcional para bloquear explícitamente un archivo para acceso de escritura exclusivo, incluso cuando existe una capacidad de fusión.
La mayoría de las herramientas de control de revisiones usarán solo uno de estos términos similares (línea de base, etiqueta, etiqueta) para referirse a la acción de identificar una instantánea ("etiquetar el proyecto") o el registro de la instantánea ("probar con la línea de base X ") . Normalmente sólo uno de los términos línea de base , etiqueta o tag se utiliza en la documentación o discusión [ cita requerida ] ; pueden considerarse sinónimos.
En la mayoría de los proyectos, algunas instantáneas son más importantes que otras, como las que se utilizan para indicar lanzamientos, ramas o hitos publicados.
Cuando tanto el término línea de base como etiqueta o etiqueta se usan juntos en el mismo contexto, etiqueta y etiqueta generalmente se refieren al mecanismo dentro de la herramienta para identificar o hacer el registro de la instantánea, y la línea de base indica el mayor significado de cualquier etiqueta dada. o etiqueta.
La mayor parte de la discusión formal sobre la gestión de la configuración utiliza el término línea de base .
Los sistemas de control de revisiones distribuidos (DRCS) adoptan un enfoque de igual a igual, a diferencia del enfoque cliente-servidor de los sistemas centralizados. En lugar de un único repositorio central en el que los clientes se sincronizan, la copia de trabajo de la base de código de cada par es un repositorio de buena fe . [9] El control de revisión distribuido realiza la sincronización mediante el intercambio de parches (conjuntos de cambios) de igual a igual. Esto da como resultado algunas diferencias importantes con respecto a un sistema centralizado:
Por el contrario, la comunicación solo es necesaria cuando se empuja o tira cambios hacia o desde otros compañeros.
Algunas de las herramientas de control de revisiones más avanzadas ofrecen muchas otras facilidades, lo que permite una integración más profunda con otras herramientas y procesos de ingeniería de software. Los complementos suelen estar disponibles para IDE como Oracle JDeveloper , IntelliJ IDEA , Eclipse y 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, [10] pero solo funciona en proyectos que ya tienen un gran historial, porque los mensajes de confirmación dependen mucho de las convenciones e idiosincrasias del proyecto.[11]
La terminología puede variar de un sistema a otro, pero algunos términos de uso común incluyen: [12]