En este artículo, comparamos técnicamente los sistemas de control de versiones más famosos (en el futuro planeamos expandir la lista):
- Primera generación
- Segunda generación
- Tercera generación
Los sistemas de control de versiones (VCS) de primera generación rastrearon cambios en archivos individuales, y la edición solo era compatible localmente y por un usuario a la vez. Los sistemas se construyeron bajo el supuesto de que todos los usuarios iniciarán sesión en sus cuentas en el mismo nodo común de Unix.
El VCS de segunda generación introdujo soporte de red, lo que condujo a repositorios centralizados con versiones "oficiales" de proyectos. Este fue un progreso significativo, ya que varios usuarios podían trabajar con el código al mismo tiempo, comprometiéndose con el mismo repositorio central. Sin embargo, confirma el acceso requerido a la red.
La tercera generación consiste en VCS distribuido, donde todas las copias del repositorio se consideran iguales, no hay un repositorio central. Esto allana el camino para los commits, ramas y fusiones que se crean localmente sin acceso a la red y se mueven a otros repositorios según sea necesario.
Cronología de lanzamiento de VCS
Para el contexto, aquí hay un gráfico que muestra las fechas en que aparecieron estas herramientas:
SCCS (Sistema de control de código fuente): primera generación
SCCS se considera uno de los primeros sistemas de control de versiones exitosos. Fue desarrollado en 1972 por Mark Rochkind de Bell Labs. El sistema está escrito en C y diseñado para rastrear las versiones del archivo fuente. Además, facilitó enormemente la búsqueda de fuentes de errores en el programa. La arquitectura básica y la sintaxis de SCCS permiten comprender las raíces de las herramientas modernas de VCS.
Arquitectura
Como la mayoría de los sistemas modernos, SCCS tiene un conjunto de comandos para trabajar con versiones de archivo:
- Archivos de registro para el seguimiento del historial en SCCS.
- Revise versiones específicas de archivos para su revisión o compilación.
- Extraer versiones específicas para editar.
- Presentamos nuevas versiones de archivos junto con comentarios que explican los cambios.
- Descarte los cambios realizados en el archivo extraído.
- Grandes cambios de ramificación y fusión.
- Registro de cambio de archivo.
Al agregar un archivo de seguimiento a SCCS, se crea un tipo especial de archivo, que se denomina
s- o
. Se conoce como el archivo fuente, solo con el prefijo
s. , y se almacena en el subdirectorio
SCCS . Por lo tanto, para el archivo
test.txt , se
test.txt un archivo de historial
test.txt en el directorio
./SCCS/ . En el momento de la creación, el archivo de historial contiene el contenido inicial del archivo fuente, así como algunos metadatos que ayudan a rastrear las versiones. Las sumas de verificación se almacenan aquí para garantizar que el contenido no se haya modificado. El contenido del archivo de historial no está comprimido ni codificado (como en la próxima generación de VCS).
Dado que el contenido del archivo fuente ahora se almacena en el archivo histórico, se puede extraer en el directorio de trabajo para verlo, compilarlo o editarlo. Puede realizar cambios en el archivo de historial, como agregar líneas, cambiar y eliminar, lo que aumenta su número de versión.
Las adiciones de archivos posteriores almacenan solo
o cambios, y no todos sus contenidos. Esto reduce el tamaño del archivo de historial. Cada delta se almacena dentro de un archivo de historial en una estructura llamada
- . Como se mencionó anteriormente, el contenido real de un archivo se copia más o menos literalmente, con secuencias de escape especiales para marcar el comienzo y el final de las secciones de contenido agregado y eliminado. Debido a que los archivos de historial de SCCS no usan compresión, generalmente son más grandes que el archivo real en el que se realiza el seguimiento de los cambios. SCCS utiliza un método llamado
, que garantiza un tiempo de recuperación constante independientemente de la antigüedad de la versión recuperada, es decir, las versiones anteriores se recuperan a la misma velocidad que las nuevas.
Es importante tener en cuenta que todos los archivos se rastrean y registran por separado. No es posible verificar los cambios en varios archivos como un solo bloque atómico, como los commits en Git. Cada archivo rastreado tiene su propio archivo de historial, en el que se almacena su historial de cambios. En el caso general, esto significa que los números de versión de varios archivos en un proyecto generalmente no coinciden. Sin embargo, estas versiones se pueden acordar editando simultáneamente todos los archivos del proyecto (sin siquiera hacer cambios reales) y agregando todos los archivos al mismo tiempo. Esto aumentará simultáneamente el número de versión para todos los archivos, manteniéndolos consistentes, pero tenga en cuenta que esto no es lo mismo que incluir varios archivos en una sola confirmación, como en Git. En SCCS, se agrega un historial individual a cada archivo, a diferencia de una confirmación grande que incluye todos los cambios a la vez.
Cuando se extrae un archivo para editarlo en SCCS, se coloca un candado sobre él, para que nadie más pueda editarlo. Esto evita que otros usuarios sobrescriban los cambios, pero también limita el desarrollo, porque en un momento dado solo un usuario puede trabajar con este archivo.
SCCS admite ramas que almacenan secuencias de cambio en un archivo específico. Puede fusionar una rama con la versión original o con otra rama.
Equipos principales
La siguiente es una lista de los comandos SCCS más comunes.
sccs create <filename.ext> : agrega un nuevo archivo a SCCS y crea un nuevo archivo de historial para él (de manera predeterminada en el directorio ./SCCS/ ).
sccs get <filename.ext> : extraiga el archivo del archivo de historial correspondiente y póngalo en el directorio de trabajo en modo de solo lectura.
sccs edit <filename.ext> : extrae el archivo del archivo de historial correspondiente para editarlo. Bloquee el archivo de historial para que otros usuarios no puedan modificarlo.
sccs delta <filename.ext> : agrega cambios al archivo especificado. El sistema solicitará un comentario, guardará los cambios en el archivo de historial y liberará el bloqueo.
sccs prt <filename.ext> : muestra el registro de cambios para el archivo monitoreado.
sccs diffs <filename.ext> : muestra las diferencias entre la copia de trabajo actual del archivo y el estado del archivo cuando se extrajo.
Para obtener más información sobre los componentes internos de SCCS, consulte
la Guía de Eric Allman y la Guía de utilidad de programación de Oracle .
Ejemplo de archivo de historial de SCCS
^Ah20562 ^As 00001/00001/00002 ^Ad D 1.3 19/11/26 14:37:08 jack 3 2 ^Ac Here is a comment. ^Ae ^As 00002/00000/00001 ^Ad D 1.2 19/11/26 14:36:00 jack 2 1 ^Ac No. ^Ae ^As 00001/00000/00000 ^Ad D 1.1 19/11/26 14:35:27 jack 1 0 ^Ac date and time created 19/11/26 14:35:27 by jack ^Ae ^Au ^AU ^Af e 0 ^At ^AT ^AI 1 Hi there ^AE 1 ^AI 2 ^AD 3 This is a test of SCCS ^AE 2 ^AE 3 ^AI 3 A test of SCCS ^AE 3
RCS (Revision Control System): primera generación
RCS fue escrito en 1982 por Walter Tihey en C como una alternativa al sistema SCCS, que en ese momento no era de código abierto.
Arquitectura
RCS tiene mucho en común con su predecesor, que incluye:
- Versionado por separado para cada archivo.
- Los cambios en varios archivos no se pueden agrupar en una sola confirmación.
- Varios usuarios no pueden editar los archivos rastreados al mismo tiempo.
- No hay soporte de red.
- Las versiones de cada archivo rastreado se almacenan en el archivo de historial correspondiente.
- Versiones de ramificación y fusión solo para archivos individuales.
Cuando un archivo se agrega por primera vez a RCS, se crea un archivo de historial correspondiente en el almacenamiento local en el directorio local
./RCS/ . Se agrega una extensión
,v , a este archivo, es decir, un archivo llamado
test.txt será rastreado por un archivo llamado
test.txt,v .
RCS utiliza un esquema de delta inversa para almacenar cambios. Cuando agrega un archivo, se guarda una instantánea completa de su contenido en el archivo de historial. Cuando el archivo se modifica y se devuelve nuevamente, se calcula un delta en función de los contenidos existentes del archivo de historial. La imagen anterior se descarta y la nueva se guarda junto con el delta para volver al estado anterior. Esto se llama
, porque para recuperar una versión anterior, RCS toma la última versión y aplica deltas secuencialmente hasta que alcanza la versión deseada. Este método le permite recuperar las versiones actuales muy rápidamente, ya que siempre está disponible una instantánea completa de la revisión actual. Sin embargo, cuanto más antigua sea la versión, más tardará la verificación, ya que debe verificar más y más deltas.
En SCCS, es diferente: lleva el mismo tiempo extraer cualquier versión. Además, la suma de verificación no se almacena en los archivos de historial de RCS, por lo que no se puede garantizar la integridad del archivo.
Equipos principales
A continuación se muestra una lista de los comandos RCS más comunes:
<filename.ext> : agregue un nuevo archivo a RCS y cree un nuevo archivo de historial para él (de manera predeterminada en el directorio ./RCS/ ).
co <filename.ext> : extrae el archivo del archivo de historial correspondiente y lo coloca en el directorio de trabajo en modo de solo lectura.
co -l <filename.ext> : extrae el archivo del archivo de historial correspondiente para editarlo. Bloquee el archivo de historial para que otros usuarios no puedan modificarlo.
ci <filename.ext> : agrega los cambios del archivo y crea una nueva revisión en el archivo de historial correspondiente.
merge <file-to-merge-into.ext> <parent.ext> <file-to-merge-from.ext> : fusiona los cambios de dos hijos modificados del mismo archivo padre.
rcsdiff <filename.ext> : muestra las diferencias entre la copia de trabajo actual del archivo y el estado del archivo cuando se extrajo.
rcsclean : elimina archivos de trabajo que no están bloqueados.
Para obtener más información sobre los componentes internos de RCS, consulte el
Manual de GNU RCS .
Ejemplo de archivo de historial de RCS
head 1.2; access; symbols; locks; strict; comment @# @; 1.2 date 2019.11.25.05.51.55; author jstopak; state Exp; branches; next 1.1; 1.1 date 2019.11.25.05.49.02; author jstopak; state Exp; branches; next ; desc @This is a test. @ 1.2 log @Edited the file. @ text @hi there, you are my bud. You are so cool! The end. @ 1.1 log @Initial revision @ text @d1 5 a5 1 hi there @
CVS (Sistema de versiones concurrentes): segunda generación
CVS fue creado por Dick Grun en 1986 para agregar soporte de red al control de versiones. También está escrito en C y marca el nacimiento de la segunda generación de herramientas VCS, gracias a las cuales los equipos de desarrollo geográficamente dispersos tienen la oportunidad de trabajar juntos en proyectos.
Arquitectura
CVS es una interfaz para RCS, tiene un nuevo conjunto de comandos para interactuar con archivos en un proyecto, pero bajo el capó se utilizan el mismo formato de archivo de historial RCS y comandos RCS. Por primera vez, CVS permitió que varios desarrolladores trabajaran con los mismos archivos simultáneamente. Esto se implementa utilizando un modelo de repositorio centralizado. El primer paso es configurar un repositorio centralizado usando CVS en el servidor remoto. Los proyectos se pueden importar al repositorio. Cuando se importa un proyecto a CVS, cada archivo se convierte en un archivo de historial
,v y se almacena en un directorio central:
. El repositorio generalmente se encuentra en un servidor remoto, cuyo acceso se realiza a través de una red local o Internet.
El desarrollador recibe una copia del módulo, que se copia en el directorio de trabajo en su computadora local. En este proceso, no se bloquean los archivos, por lo que no hay límite en el número de desarrolladores que pueden trabajar simultáneamente con el módulo. Los desarrolladores pueden modificar sus archivos y confirmar los cambios según sea necesario (commit). Si un desarrollador confirma un cambio, otros desarrolladores deben actualizar sus copias de trabajo utilizando el proceso de fusión (generalmente) automatizado antes de confirmar sus cambios. A veces tiene que resolver manualmente los conflictos de fusión antes de comprometerse. CVS también ofrece la capacidad de crear y fusionar sucursales.
Equipos principales
export CVSROOT=<path/to/repository> : establezca el directorio raíz del repositorio CVS, por lo que no necesita especificarlo en cada comando.
cvs import -m 'Import module' <module-name> <vendor-tag> <release-tag> : importe directorios con archivos en el módulo CVS. Antes de comenzar este proceso, vaya al directorio raíz del proyecto.
cvs checkout <module-name> : copie el módulo al directorio de trabajo.
cvs commit <filename.ext> : devuelve el archivo modificado al módulo en el repositorio central.
cvs add <filename.txt> : agrega un nuevo archivo para rastrear los cambios.
cvs update : actualice la copia de trabajo fusionando los cambios confirmados que existen en el repositorio central pero no en la copia de trabajo.
cvs status : muestra información general sobre la copia de trabajo extraída del módulo.
cvs tag <tag-name> <files> : agrega una etiqueta a un archivo o conjunto de archivos.
cvs tag -b <new-branch-name> : crea una nueva rama en el repositorio (necesitas extraerla antes del trabajo local).
cvs checkout -r <branch-name> : extrae una rama existente al directorio de trabajo.
cvs update -j <branch-to-merge> : cvs update -j <branch-to-merge> una rama existente con una copia de trabajo local.
Para obtener más información sobre los componentes internos de CVS, consulte el
Manual de GNU CVS y
el artículo de Dick Grohn .
Ejemplo de archivo de historial CVS
head 1.1; branch 1.1.1; access ; symbols start:1.1.1.1 jack:1.1.1; locks ; strict; comment @# @; 1.1 date 2019.11.26.18.45.07; author jstopak; state Exp; branches 1.1.1.1; next ; commitid zsEBhVyPc4lonoMB; 1.1.1.1 date 2019.11.26.18.45.07; author jstopak; state Exp; branches ; next ; commitid zsEBhVyPc4lonoMB; desc @@ 1.1 log @Initial revision @ text @hi there @ 1.1.1.1 log @Imported sources @ text @@
SVN (Subversion): Segunda Generación
Subversion fue creada en 2000 por Collabnet Inc. y actualmente cuenta con el respaldo de Apache Software Foundation. El sistema está escrito en C y está diseñado como una solución centralizada más confiable que CVS.
Arquitectura
Al igual que CVS, Subversion usa un modelo de repositorio centralizado. Los usuarios remotos requieren una conexión de red para comprometerse con el repositorio central.
Subversion introdujo la funcionalidad de los commits atómicos con la garantía de que el commit es completamente exitoso o completamente cancelado en caso de un problema. En CVS, en el caso de un mal funcionamiento en medio de una confirmación (por ejemplo, debido a una falla de la red), el repositorio podría permanecer en un estado dañado e inconsistente. Además, una confirmación o versión en Subversion puede incluir varios archivos y directorios. Esto es importante porque le permite rastrear conjuntos de cambios relacionados juntos como un bloque agrupado, y no por separado para cada archivo, como en los sistemas del pasado.
Subversion actualmente utiliza el sistema de archivos FSFS (Sistema de archivos sobre el sistema de archivos). Aquí se crea una base de datos con la estructura de archivos y directorios que corresponden al sistema de archivos host. Una característica única de FSFS es que está diseñado para rastrear no solo archivos y directorios, sino también sus versiones. Este es un sistema de archivos sensible al tiempo. Los directorios también son objetos completos en Subversion. Puede confirmar directorios vacíos en el sistema, mientras que el resto (incluso Git) no los nota.
Cuando crea un repositorio de Subversion, se crea una base de datos (casi) vacía de archivos y carpetas en su composición. Se crea el directorio
db/revs , que almacena toda la información de seguimiento de versiones para los archivos agregados (comprometidos). Cada confirmación (que puede incluir cambios en varios archivos) se almacena en un nuevo archivo en el directorio
revs , y se le asigna un nombre con un identificador numérico secuencial que comienza con 1. La primera confirmación guarda el contenido completo del archivo. Las confirmaciones futuras del mismo archivo solo guardarán los cambios, que también se denominan
o deltas, para ahorrar espacio. Además, los deltas se comprimen usando algoritmos de compresión
lz4 o
zlib para reducir el tamaño.
Tal sistema solo funciona hasta cierto punto. Aunque los deltas ahorran espacio, pero si hay muchos de ellos, se requiere mucho tiempo para la operación, ya que todos los deltas deben procesarse para recrear el estado actual del archivo. Por este motivo, de manera predeterminada, Subversion guarda hasta 1023 deltas por archivo y luego realiza una nueva copia completa del archivo. Esto proporciona un buen equilibrio de almacenamiento y velocidad.
SVN no utiliza el sistema habitual de ramificación y etiquetado. La plantilla de repositorio de Subversion normal contiene tres carpetas en la raíz:
El directorio
trunk/ se usa para la versión de producción del proyecto. El directorio
branches/ : para almacenar subcarpetas correspondientes a sucursales individuales. El directorio
tags/ es para almacenar etiquetas que representan versiones específicas (generalmente significativas) de un proyecto.
Equipos principales
svn create <path-to-repository> : crea un nuevo shell de repositorio vacío en el directorio especificado.
svn import <path-to-project> <svn-url> : importa el directorio de archivos en el repositorio Subversion especificado.
svn checkout <svn-path> <path-to-checkout> : copie el repositorio en el directorio de trabajo.
svn commit -m 'Commit message' : confirma un conjunto de archivos y carpetas modificados junto con el mensaje.
svn add <filename.txt> : agrega un nuevo archivo para rastrear los cambios.
svn update : actualiza la copia de trabajo fusionando los cambios confirmados que existen en el repositorio central pero no en la copia de trabajo.
svn status : muestra una lista de archivos monitoreados que han cambiado en el directorio de trabajo (si corresponde).
svn info : información general sobre la copia extraída.
svn copy <branch-to-copy> <new-branch-path-and-name> : crea una nueva rama copiando una existente.
svn switch <existing-branch> : cambia el directorio de trabajo a una rama existente. Esto le permitirá tomar archivos desde allí.
svn merge <existing-branch> : fusiona la rama especificada con la actual copiada en el directorio de trabajo. Tenga en cuenta que deberá comprometerse más tarde.
svn log : muestra el historial de confirmaciones y los mensajes correspondientes para la rama activa.
Para obtener más información sobre los componentes internos de SVN, consulte
Subversion Versioning .
Archivo de historial SVN de muestra
DELTA SVN^B^@^@ ^B ^A<89> hi there ENDREP id: 2-1.0.r1/4 type: file count: 0 text: 1 3 21 9 12f6bb1941df66b8f138a446d4e8670c 279d9035886d4c0427549863c4c2101e4a63e041 0-0/_4 cpath: /trunk/hi.txt copyroot: 0 / DELTA SVN^B^@^@$^B%^A¤$K 6 hi.txt V 15 file 2-1.0.r1/4 END ENDREP id: 0-1.0.r1/6 type: dir count: 0 text: 1 5 48 36 d84cb1c29105ee7739f3e834178e6345 - - cpath: /trunk copyroot: 0 / DELTA SVN^B^@^@'^B#^A¢'K 5 trunk V 14 dir 0-1.0.r1/6 END ENDREP id: 0.0.r1/2 type: dir pred: 0.0.r0/2 count: 1 text: 1 7 46 34 1d30e888ec9e633100992b752c2ff4c2 - - cpath: / copyroot: 0 / _0.0.t0-0 add-dir false false false /trunk _2.0.t0-0 add-file true false false /trunk/hi.txt L2P-INDEX ^A<80>@^A^A^A^M^H^@ä^H÷^Aé^FDÎ^Bzè^AP2L-INDEX ^A<91>^E<80><80>@^A?^@'2^@<8d>»Ý<90>^C§^A^X^@õ ½½^N= ^@ü<8d>Ôã^Ft^V^@<92><9a><89>Ã^E; ^@<8a>åw|I^@<88><83>Î<93>^L`^M^@ù<92>À^Eïú?^[^@^@657 6aad60ec758d121d5181ea4b81a9f5f4 688 75f59082c8b5ab687ae87708432ca406I
Git: tercera generación
El sistema Git fue desarrollado en 2005 por Linus Torvalds (creador de Linux). Está escrito principalmente en C en combinación con algunos scripts de línea de comandos. Difiere de VCS en funciones, flexibilidad y velocidad. Torvalds originalmente escribió el sistema para la base de código de Linux, pero con el tiempo su alcance se ha expandido, y hoy es el sistema de control de versiones más popular del mundo.
Arquitectura
Git es un sistema distribuido. No hay un repositorio central: todas las copias se crean de la misma manera, lo cual es muy diferente del VCS de segunda generación, donde el trabajo se basa en agregar y extraer archivos del repositorio central. Esto significa que los desarrolladores pueden intercambiar cambios entre ellos inmediatamente antes de fusionar sus cambios en una rama oficial.
Además, los desarrolladores pueden realizar sus cambios en la copia local del repositorio sin el conocimiento de otros repositorios. Esto permite confirmaciones sin estar conectado a una red o Internet. Los desarrolladores pueden trabajar localmente fuera de línea, hasta que estén listos para compartir su trabajo con otros. En este punto, los cambios se envían a otros repositorios para su verificación, prueba o implementación.
Cuando se agrega un archivo para el seguimiento en Git, se comprime usando el algoritmo de compresión
zlib . El resultado se procesa mediante la función hash SHA-1. Esto proporciona un hash único que coincide específicamente con el contenido de este archivo. Git lo almacena en la
, que se encuentra en una carpeta oculta
.git/objects . El nombre del archivo es el hash generado y el archivo contiene contenido comprimido. Estos archivos se llaman
y se crean cada vez que se agrega un nuevo archivo (o una versión modificada de un archivo existente) al repositorio.
Git implementa un índice de preparación, que actúa como un área intermedia para los cambios que se están preparando para la confirmación. A medida que se preparan nuevos cambios, se hace referencia a su contenido comprimido en un archivo de índice especial, que toma la forma de un objeto de
.
Un árbol es un objeto Git que asocia blobs con sus nombres de archivos reales, permisos de archivos y enlaces a otros árboles y, por lo tanto, representa el estado de un conjunto específico de archivos y directorios. Cuando se preparan todos los cambios relevantes para la confirmación, el árbol de índice se puede confirmar en el repositorio que crea el objeto (objetos sueltos). Aquí no se usan diferencias para ahorrar espacio, lo que hace que Git sea muy rápido, ya que el contenido completo de cada versión del archivo está disponible como un objeto libre. Sin embargo, algunas operaciones, como enviar confirmaciones a un repositorio remoto, almacenar una gran cantidad de objetos o ejecutar manualmente el comando de recolección de basura Git, hacen que los objetos se vuelvan a empaquetar .packcon el contenido del objeto, y para cada uno de ellos se crea un archivo .idx(o índice) con un enlace a los objetos empaquetados y su ubicación en el archivo por lotes.Cuando las ramas se mueven o se recuperan de repositorios remotos, estos archivos por lotes se transfieren a través de la red. Al estirar o extraer ramas, los archivos de paquete se desempaquetan para crear objetos libres en el repositorio de objetos.Equipos principales
git init: inicializa el directorio actual como un repositorio Git ( .gitse crea una carpeta oculta y su contenido).
git clone <git-url> : Descargue una copia del repositorio de Git en la URL especificada.
git add <filename.ext> : agrega un archivo sin seguimiento o modificado al área de preparación (crea los registros correspondientes en la base de datos de objetos).
git commit -m 'Commit message' : compromete un conjunto de archivos y carpetas modificados junto con un mensaje de confirmación.
git status : muestra el estado del directorio de trabajo, la rama actual, los archivos no rastreados, los archivos modificados, etc.
git branch <new-branch> : crea una nueva rama basada en la rama extraída actual.
git checkout <branch> : extrae la rama especificada al directorio de trabajo.
git merge <branch> : fusiona la rama especificada con la actual, que se extrae en el directorio de trabajo.
git pull : Actualice la copia de trabajo combinando los cambios confirmados que existen en el repositorio remoto, pero no en la copia de trabajo.
git push : empaqueta objetos libres para confirmaciones locales de la rama activa en archivos de paquete y transfiere a un repositorio remoto.
git log : muestra el historial de confirmaciones y los mensajes correspondientes para la rama activa.
git stash : guarda todos los cambios no confirmados del directorio de trabajo en la memoria caché para su posterior recuperación.
Si desea saber cómo funciona el código Git, consulte la Guía de inicio de Git . Para obtener más información sobre los componentes internos, consulte el capítulo correspondiente en el libro Pro Git .Ejemplo blob, tree y commit git
Blob con un hash 37d4e6c5c48ba0d245164c4e10d5f41140cab980: hi there
Objeto de árbol con un hash b769f35b07fbe0076dcfc36fd80c121d747ccc04: 100644 blob 37d4e6c5c48ba0d245164c4e10d5f41140cab980hi.txt
Hash commit dc512627287a61f6111705151f4e53f204fbda9b: tree b769f35b07fbe0076dcfc36fd80c121d747ccc04 author Jacob Stopak 1574915303 -0800 committer Jacob Stopak 1574915303 -0800 Initial commit
Mercurial: tercera generación
Mercurial fue creado en 2005 por Matt McCall y escrito en Python. También está diseñado para alojar la base de código de Linux, pero Git finalmente fue elegido para esta tarea. Este es el segundo sistema de control de versiones más popular, aunque se usa con mucha menos frecuencia.Arquitectura
Mercurial también es un sistema distribuido que permite a cualquier número de desarrolladores trabajar con su copia del proyecto independientemente de los demás. Mercurial utiliza muchas de las mismas tecnologías que Git, incluida la compresión y el hash SHA-1, pero lo hace de manera diferente.Cuando se confirma un nuevo archivo para el seguimiento en Mercurial, se crea un archivo correspondiente revlogen un directorio oculto .hg/store/data/. Puede considerar el archivo revlog(registro de cambios) como una versión actualizada en VCS anteriores como CVS, RCS y SCCS. A diferencia de Git, que crea un nuevo blob para cada versión de cada archivo preparado, Mercurial simplemente crea una nueva entrada de revlog para este archivo. Para ahorrar espacio, cada nuevo registro contiene solo el delta de la versión anterior. Cuando se alcanza el número umbral de deltas, la instantánea completa del archivo se guarda nuevamente. Esto reduce el tiempo de búsqueda al procesar una gran cantidad de deltas para restaurar una versión específica de un archivo.Cada revlog se nombra de acuerdo con el archivo que está rastreando, pero con la extensión .io .d. Los archivos .dcontienen un delta comprimido. Los archivos .ise usan como índices para rastrear rápidamente diferentes versiones dentro de los archivos.d. Para archivos pequeños con pocos cambios, los índices y el contenido se almacenan dentro de los archivos .i. Las entradas de Revlog están comprimidas para el rendimiento y hash para su identificación. Estos valores hash se nombran nodeid.En cada confirmación, Mercurial realiza un seguimiento de todas las versiones de los archivos en esta confirmación en lo que se llama a nodeid.Finalmente, Mercurial usa otro tipo de revlog llamado changelog, es decir, un registro de cambios. Esta es una lista de entradas que asocian cada confirmación con la siguiente información:- manifest nodeid: un conjunto completo de versiones de archivo que existen en un punto particular en el tiempo.
- uno o dos nodos para confirmaciones principales: esto permite que Mercurial construya una línea de tiempo o una rama del historial del proyecto. Se almacenan uno o dos identificadores principales según el tipo de confirmación (normal o fusión).
- Autor de compromiso
- Fecha de compromiso
- Mensaje de compromiso
Cada entrada del registro de cambios también genera un hash conocido como su nodeid.Equipos principales
hg init: inicializa el directorio actual como un repositorio Mercurial (crea una carpeta oculta .hgy su contenido).
hg clone <hg-url> : Descargue una copia del repositorio de Mercurial en la URL especificada.
hg add <filename.ext> : Agregue un nuevo archivo para realizar un seguimiento de los cambios.
hg commit -m 'Commit message' : confirma el conjunto de archivos y carpetas modificados junto con el mensaje de confirmación.
hg status : muestra información relacionada con el estado del directorio de trabajo, archivos no rastreados, archivos modificados, etc.
hg update <revision> : extrae la rama especificada al directorio de trabajo.
hg merge <branch> : fusiona la rama especificada con la actual extraída en el directorio de trabajo.
hg pull : Descargue nuevas versiones de un repositorio remoto, pero no las combine en un directorio de trabajo.
hg push : Transfiera nuevas versiones al repositorio remoto.
hg log : Muestra el historial de confirmaciones y mensajes relacionados para la rama activa.
Ejemplos de archivos mercuriales
Manifiesto hey.txt208b6e0998e8099b16ad0e43f036ec745d58ec04 hi.txt74568dc1a5b9047c8041edd99dd6f566e78d3a42
Registro de cambios (registro de cambios): b8ee947ce6f25b84c22fbefecab99ea918fc0969 Jacob Stopak 1575082451 28800 hey.txt Add hey.txt
Información adicional sobre el dispositivo Mercurial: