Comparación de software de control de versiones

Las siguientes tablas describen los atributos de sistemas de software de control de versiones y gestión de configuración de software (SCM) notables que pueden usarse para comparar y contrastar los distintos sistemas.

Para el software de SCM no apto para código fuente , consulte Comparación de software de gestión de configuración de código abierto .

información general

La siguiente tabla contiene atributos relativamente generales de los sistemas de software de control de versiones, incluidos:

• Modelo de repositorio, la relación entre copias del repositorio de código fuente
  • Cliente-servidor : los usuarios acceden a un repositorio maestro a través de un cliente ; normalmente, sus máquinas locales solo contienen una copia de trabajo de un árbol de proyecto. Los cambios en una copia de trabajo deben confirmarse en el repositorio maestro antes de que se propaguen a otros usuarios.
  • Los repositorios distribuidos actúan como pares y los usuarios normalmente tienen un repositorio local con el historial de versiones disponible, además de sus copias de trabajo.
• Modelo de concurrencia, cómo se gestionan los cambios en la copia de trabajo para evitar que ediciones simultáneas provoquen datos sin sentido en el repositorio.
  • Bloqueo , los cambios no se permiten hasta que el usuario solicite y reciba un bloqueo exclusivo en el archivo desde el repositorio maestro.
  • Fusionar : los usuarios pueden editar archivos libremente, pero se les informa de posibles conflictos al registrar sus cambios en el repositorio, con lo que el sistema de control de versiones puede fusionar los cambios de ambos lados o dejar que el usuario decida cuándo surgen los conflictos . Los sistemas de control de versiones distribuidos suelen utilizar un modelo de concurrencia de fusión.

Información técnica

La siguiente tabla muestra los detalles técnicos de algunos programas de control de versiones conocidos. Estos se clasifican según los siguientes encabezados:

Explicación de la tabla

• Software : El nombre de la aplicación que se describe.
• Lenguaje de programación : El lenguaje de codificación en el que se está desarrollando la aplicación.
• Método de almacenamiento : describe la forma en que se almacenan los archivos en el repositorio. Una instantánea indica que un archivo confirmado se almacena en su totalidad, generalmente comprimido. Un conjunto de cambios , en este contexto, indica que un archivo confirmado se almacena en forma de una diferencia entre la versión anterior o la siguiente.
• Alcance del cambio : describe si los cambios se registran para archivos individuales o para árboles de directorios completos .
• Identificadores de revisión : se utilizan internamente para identificar versiones específicas de archivos en el repositorio. Los sistemas pueden utilizar identificadores pseudoaleatorios , hashes de contenido de revisiones o nombres de archivo con números de versión secuenciales (espacio de nombres). Con Integrated Difference, las revisiones se basan en los propios conjuntos de cambios, que pueden describir cambios en más de un archivo.
• Protocolos de red : enumera los protocolos utilizados para la sincronización de cambios .
• Tamaño del código fuente : proporciona el tamaño del código fuente en megabytes.

Características

La siguiente tabla clasifica algunos programas conocidos en función de sus características y capacidades.

Explicación de la tabla

• Software : El nombre de la aplicación que se describe.
• Commits atómicos : se refiere a una garantía de que se realizarán todos los cambios o de que no se realizará ningún cambio en absoluto.
• Cambio de nombre de archivos : describe si un sistema permite cambiar el nombre de los archivos conservando su historial de versiones.
• Combinar cambios de nombre de archivo : describe si un sistema puede combinar los cambios realizados en un archivo de una rama en el mismo archivo que se renombró en otra rama (o viceversa). Si se renombró el mismo archivo en ambas ramas, existe un conflicto de cambio de nombre que el usuario debe resolver.
• Enlaces simbólicos : describe si un sistema permite el control de revisión de enlaces simbólicos como en el caso de los archivos normales. Algunas personas consideran que el control de versiones de los enlaces simbólicos es una característica y otras una violación de la seguridad (por ejemplo, un enlace simbólico a /etc/passwd). Los enlaces simbólicos solo se admiten en determinadas plataformas, según el software.
• Ganchos previos o posteriores al evento : indican la capacidad de activar comandos antes o después de que se lleve a cabo una acción, como una confirmación.
• Revisiones firmadas : se refiere a la firma digital integrada de revisiones, en un formato comoOpenPGP.
• Seguimiento de fusión : describe si un sistema recuerda qué cambios se han fusionado entre qué ramas y solo fusiona los cambios que faltan al fusionar una rama con otra.
• Conversiones de fin de línea : describe si un sistema puede adaptar los caracteres de fin de línea para archivos de texto de modo que coincidan con el estilo de fin de línea del sistema operativo en el que se utiliza. La granularidad del control varía. Subversion, por ejemplo, se puede configurar para manejar los caracteres de fin de línea de forma diferente según el tipo de archivo, mientras que Perforce convierte todos los archivos de texto según una única configuración por cliente.
• Etiquetas : indica si se pueden dar nombres significativos a revisiones específicas, independientemente de si estos nombres se denominan etiquetas o rótulos.
• Soporte internacional : indica si el software tiene soporte para múltiples entornos de idiomas y sistemas operativos.
• Compatibilidad con nombres de archivo Unicode : indica si el software tiene soporte para interoperaciones bajo sistemas de archivos que utilizan diferentes codificaciones de caracteres .
• Admite repositorios grandes : ¿Puede el sistema gestionar repositorios de alrededor de un gigabyte o más de manera efectiva?

Funciones avanzadas

A continuación se presentan algunas características y capacidades más avanzadas de algunos software de control de versiones:

Explicación de la tabla

• Expansión de palabras clave : admite la expansión automática de palabras clave como el número de revisión del archivo.
• Confirmaciones interactivas : las confirmaciones interactivas permiten al usuario seleccionar líneas de código comunes utilizadas para anclar archivos (trozos de parche) que se convierten en parte de una confirmación (dejando los cambios no seleccionados como cambios en la copia de trabajo), en lugar de tener solo una granularidad a nivel de archivo.
• Referencias externas : incorporación de repositorios externos en el árbol de fuentes
• Extracción/clonación parcial : capacidad de extraer o clonar solo un subdirectorio específico de un repositorio.
• Permisos : rastrea los bits de permisos de archivos en el historial de revisiones.
• Conservación de la marca de tiempo : sobrescribe elúltimoatributo del sistema de archivos modificado con la hora de confirmación al momento de la compra.
• Herramienta de fusión automática personalizada : la fusión automática se puede intentar con cualquier herramienta que elija el usuario (con suerte, configurable para cada archivo)
• Formatos admitidos : soporte de lectura/escritura o solo lectura (conversión, potencialmente repetida)
• Caché de compilación compartida de objetos derivados : la capacidad de sustituir automáticamente (wink-in) objetos derivados que fueron compilados por otros clientes confederados que comparten exactamente las mismas dependencias en lugar de reconstruirlos localmente

Comandos básicos

Esta tabla proporciona más información sobre los comandos proporcionados en los software de control de versiones.

Explicación de la tabla

• Repositorio init : crea un nuevo repositorio vacío (es decir, base de datos de control de versiones)
• clone : ​​crea una instancia idéntica de un repositorio (en una transacción segura)
• pull : descargar revisiones de un repositorio remoto a un repositorio local
• push : Cargar revisiones desde un repositorio local a un repositorio remoto
• Ramas locales : crea una rama local que no existe en el repositorio remoto original
• checkout : crea una copia de trabajo local desde un repositorio (remoto)
• actualización : Actualizar los archivos en una copia de trabajo con la última versión de un repositorio
• bloquear : bloquear archivos en un repositorio para que otros usuarios no puedan modificarlos
• Agregar : Marcar los archivos especificados para que se agreguen al repositorio en la próxima confirmación
• eliminar : marca los archivos especificados para que se eliminen en la próxima confirmación (nota: mantiene un historial de revisión coherente de antes y en el momento de la eliminación).
• mover : marcar archivos específicos para moverlos a una nueva ubicación en la próxima confirmación
• Copiar : Marcar los archivos especificados para que se copien en la próxima confirmación
• fusionar : aplicar las diferencias entre dos fuentes a una ruta de copia de trabajo
• commit : Registrar cambios en el repositorio
• revertir : restaurar el archivo de copia de trabajo desde el repositorio
• generar archivo de paquete : crea un archivo que contiene un conjunto comprimido de cambios en un repositorio determinado
• rebase : reenvío de confirmaciones locales al encabezado ascendente actualizado
• Nota: Los comandos en rectángulos verdes que no están entre corchetes se encuentran en una línea de comandos interactiva. El texto entre corchetes es una explicación de dónde encontrar una funcionalidad equivalente.

Comandos avanzados

La tabla muestra los comandos para ejecutar tareas y funcionalidades comunes de algunos software de control de versiones.

Explicación de la tabla

• Alias ​​de comandos : crea alias personalizados para comandos específicos o una combinación de ellos
• Bloquear/desbloquear : bloquea exclusivamente un archivo para evitar que otros lo editen
• Archivar/desarchivar : dejar de lado temporalmente parte o la totalidad de los cambios en el directorio de trabajo
• Revertir : eliminar un parche/revisión del historial
• Selección selectiva : mover sólo algunas revisiones de una rama a otra (en lugar de fusionar las ramas)
• Bisect : búsqueda binaria del historial de origen para encontrar un cambio que introdujo o solucionó una regresión
• Entrante/saliente : consulta las diferencias entre el repositorio local y uno remoto (los parches que se obtendrán/enviarán en un pull/push)
• Grep : busca en el repositorio líneas que coincidan con un patrón
• Registro : incluye solo algunos cambios en un archivo en una confirmación y no otros
• Nota : Los comandos en rectángulos verdes que no están entre corchetes se encuentran en una línea de comandos interactiva. El texto entre corchetes es una explicación de dónde encontrar una funcionalidad equivalente.

Interfaces de usuario

La tabla proporciona las especificaciones de la interfaz web, GUI e IDE de algunos software de control de versiones.

Explicación de la tabla

• Software : El nombre de la aplicación que se describe.
• Interfaz web : describe si la aplicación de software contiene una interfaz web. Una interfaz web podría permitir que el software publique datos de diagnóstico en un sitio web o incluso podría permitir el control remoto de la aplicación de software.
• GUI : una GUI es una interfaz gráfica de usuario. Si un producto de software incluye una GUI, se puede acceder a su funcionalidad a través de las ventanas de la aplicación, en lugar de hacerlo escribiendo comandos en el símbolo del sistema, como en una interfaz DOS.
• Complementos : las funciones están disponibles a través de un entorno de desarrollo integrado . La función mínima debe ser la de enumerar el estado de revisión de un archivo y registrar la entrada y salida de archivos.

Historia y adopción

Aquí hay algunos metadatos y antecedentes históricos de algunos software de control de versiones.

Explicación de la tabla

• Software : El nombre de la aplicación que se describe.
• Historia : describe brevemente los orígenes y el desarrollo del software.
• Usuarios actuales notables : es una lista de proyectos conocidos que utilizan el software como su sistema principal de control de revisiones, excluyendo el software en sí, seguido de un enlace a una lista completa si está disponible.

Véase también

• Comparación de las instalaciones de alojamiento de código fuente
• Lista de software de control de versiones

Notas

1. En ClearCase, se puede configurar un disparador para permitir el modelo de bloqueo, y esto se hace en muchos sitios. Sin embargo, el desarrollo de ClearCase generalmente se lleva a cabo en ramas privadas donde a cada desarrollador se le asigna su propia rama, por lo que el modelo de concurrencia de bloqueo frente a fusión no importa tanto. El código se fusiona nuevamente con la rama principal una vez que el desarrollador está listo para entregar su código al proyecto.
2. RTC no es un sistema de control de revisión distribuido; pero tiene algunas características distribuidas que se pueden configurar
3. Existen varias bifurcaciones de las fuentes originales de Unix, de las cuales solo una se mantiene activamente
4. Si bien es posible que varios usuarios editen la misma versión de un archivo simultáneamente, solo uno de ellos puede volver a escribir los cambios.
5. Si bien algunas bifurcaciones de SCCS son software libre, otras permanecen cerradas como partes de distribuciones comerciales de Unix.
6. En Subversion, un atributo de archivo habilita el modelo de bloqueo para cada archivo. Este atributo de archivo se puede configurar automáticamente mediante expresiones comodín en el nombre del archivo.
7. Los módulos críticos de Bazaar están escritos en Pyrex . Se traducen automáticamente a C puro ; excepto el módulo de ordenación por paciencia , utilizado en la resolución de fusiones, que está escrito directamente en lenguaje C.
8. Un paquete de Bazaar es un resumen de diferencias, con suficiente información adicional para preservar el historial.
9. Instantáneas con archivos binarios. Se está discutiendo la posibilidad de tener conjuntos de cambios binarios en el futuro (darcs 3)
10. 4 MB de los cuales son sqlite3.c
11. Los números de revisión de Mercurial son locales para cada repositorio; pueden diferir de un repositorio a otro dependiendo del orden en el que se realicen las fusiones.
12. Las revisiones de Monotone representan conjuntos de cambios y sus manifiestos representan instantáneas; cada revisión está vinculada a algún manifiesto. Pero los manifiestos son construcciones heredadas, ya no se guardan en la base de datos y se reconstruyen sobre la marcha si es necesario. El trabajo real ahora se realiza en listas que son estructuras híbridas de instantáneas y conjuntos de cambios.
13. Los gemelos malvados son comunes. Los gemelos malvados en SCM, no en Hollywood Archivado el 16 de octubre de 2013 en Wayback Machine.
14. Se puede habilitar la confirmación atómica para el check-in individual de las notas de la versión ClearCase 7.1.1.
15. Ver preguntas frecuentes
16. Cada parche de darcs tiene un identificador único, es imposible fusionar dos veces el mismo parche en un repositorio (sin modificar destructivamente el historial usando comandos "inseguros").
17. Aunque almacena (y muestra de forma predeterminada) nombres de archivo de 8 bits. Ver preguntas frecuentes
18. Uso de atributos de revisión de elementos (demostración "Trabajar con elementos", que cubre los atributos definidos por el usuario Archivado el 4 de marzo de 2016 en Wayback Machine ).
19. En el sentido de que sus mensajes e interfaces gráficas solo tienen localización en inglés, aunque el software está certificado para funcionar correctamente en sistemas operativos de varios idiomas.
20. Controlado por la configuración 'crnl-glob' ([1])
21. Git no realiza un seguimiento explícito de los cambios de nombre, ya que por diseño no realiza un seguimiento de los archivos individuales. Los cambios de nombre y la división de los archivos de origen se detectan después del hecho, si el contenido del archivo no cambia drásticamente.
22. Desde git-1.7.9 (ver notas de la versión Archivado el 15 de abril de 2013 en archive.today ). Las versiones anteriores no firman las confirmaciones, solo las etiquetas (ver la opción -s en la página del manual git-tag(1))
23. Los nombres de archivos UTF-8 son compatibles a partir de la versión 1.7.10 (notas de la versión de MSysGit).
24. Git tiene algunos problemas con repositorios muy grandes. Consulte la sección Mejor compatibilidad con archivos grandes y la sección Diseño de un formato de índice más rápido en SoC 2012 Ideas.
25. Los paquetes de cambio con integridad habilitada proporcionan un flujo de trabajo completo y firmas digitales compatibles con 21 CFR Parte 11 contra el elemento que controla el paquete de cambio.
26. 2009 SP5 agregó una función para fusionar rutas de desarrollo infantil.
27. Mercurial incluye internacionalización para más de 10 idiomas a partir de 2017.
28. El soporte depende del sistema operativo anfitrión y es compatible con Unix, pero no con sistemas operativos Windows, debido a la falta de compatibilidad con el host. Ver [2]
29. Se podría hacer a través de ganchos a nivel de usuario.
30. Perforce controlará la versión de los enlaces simbólicos, pero no reconocerá sus propias vistas controladas por versión (árboles de archivos locales), si accede a ellas a través de enlaces simbólicos.
31. A través de los componentes del comportamiento del proceso: Asesores de operaciones y Participantes de operaciones. http://jazz.net/library/article/292
32. Si bien el código fuente de SCCS se escribió para admitir la internacionalización, solo existen textos de mensajes en inglés.
33. StarTeam admite confirmaciones atómicas a partir de la versión 2006
34. Subversion puede mover un archivo y conservar su historial, siempre y cuando el destino del movimiento esté en el mismo repositorio de Subversion que el origen. Los movimientos entre repositorios requieren herramientas de terceros.
35. Desde la versión 1.8 de SVN, Subversion admite un seguimiento de movimientos mejorado en el lado del cliente. En el lado del servidor, aún no es compatible.
36. "Firma de conjuntos de cambios". Listas de correo de Apache Subversion . Consultado el 5 de agosto de 2016 .
37. Novedades de SVN 1.5: <http://subversion.apache.org/docs/release-notes/1.5.html#merge-tracking>. Una herramienta independiente, "svnmerge", <[3]> proporciona seguimiento de fusiones para versiones anteriores.
38. En Subversion, las etiquetas son un caso especial del concepto más genérico de "copia barata" de Subversion. Por convención, una etiqueta es una copia en un directorio llamado "etiquetas". Debido a esto, incluso las etiquetas tienen versiones. Vea http://svnbook.red-bean.com/nightly/en/svn.branchmerge.tags.html para obtener más información. La razón para el soporte parcial en la tabla es que la emulación de etiquetas de Subversion de esta manera no cumple con el requisito de que el nombre de la etiqueta se pueda usar en lugar de cualquier identificador de revisión donde sea necesario que el usuario ingrese uno. Esta columna no tendría sentido si la definición se relajara lo suficiente para abarcar el enfoque de Subversion, ya que todos los sistemas de control de versiones admiten la ramificación y, por lo tanto, también admitirían etiquetas.
39. en versiones asiáticas (v6.6a a v7.1a) y desde la versión 7.2 en general
40. El historial de cambios de versión se elimina al cambiar el nombre; no se hace referencia al nombre antiguo.
41. aún no implementado
42. No se puede deshabilitar en vistas dinámicas.
43. Usando el alias del archivo CVSROOT/modules.
44. CVS registra el bit ejecutable cuando se agrega un archivo, pero no permite cambiarlo posteriormente.
45. Esta es una función GUI compatible con TortoiseCVS y WinCVS, los cuales incluyen/utilizan CVSNT.
46. Igual que CVS, más la capacidad de tener repositorios replicados, incluidos repositorios "sombra".
47. Utilice el nombre del módulo/directorio o un alias creado usando el archivo de administración CVSROOT/modules o CVSROOT/modules2.
48. CVSNT admite esto cuando la herramienta de creación/compilación utilizada también lo admite.
49. Darcs puede realizar verificaciones dispersas desde puntos de control explícitos en repositorios darcs-1, pero no desde los de darcs-2 ^{[ cita requerida ]}
50. Darcs puede detectar automáticamente los scripts #! y hacerlos ejecutables al finalizar la compra.
51. Uso de la funcionalidad de subproyecto (Portafolio de documentación | Guía del usuario | Cómo relacionar un proyecto o flujo con otros objetos).
52. Los pagos se pueden anidar con "fossil open –nested"
53. Las preguntas frecuentes de Git establecen que la expansión de palabras clave no es algo bueno
54. agregue -i y agregue -p , consulte la página del manual git-add(1)
55. Las preguntas frecuentes de Git explican por qué se considera perjudicial preservar el tiempo de modificación
56. Configurable en el servidor como una opción de proyecto y en el cliente como una opción de usuario.
57. A través de herramientas de terceros como Tortoise SVN .
58. SVN no puede conservar las horas de modificación de los archivos. A pedido del cliente, puede restaurar la hora de registro como la hora de la última modificación. Deshabilitado de manera predeterminada.
59. El tipo MIME del archivo debe detectarse como un tipo MIME "legible para humanos", incluso si la herramienta de combinación puede trabajar con archivos no legibles para humanos
60. Rama independiente, archivada desde el original el 4 de marzo de 2016 , consultada el 6 de noviembre de 2014
61. Repositorio compartido, archivado desde el original el 4 de marzo de 2016 , consultado el 6 de noviembre de 2014
62. Rama independiente, archivada desde el original el 4 de marzo de 2016 , consultada el 6 de noviembre de 2014
63. Heavyweight Checkout y Lightweight Checkout, archivado desde el original el 2016-06-30 , consultado el 2014-11-06
64. complemento de rebase
65. darcs no tiene ramas con nombre, locales o no, la ramificación se maneja únicamente a través de la clonación del repositorio
66. darcs send prepara un paquete de parches, por defecto lo envía por correo pero puede enviarlo a un archivo en su lugar
67. Las copias se detectan después del hecho, de forma muy similar a los cambios de nombre.
68. Los marcadores Mercurial son similares a las sucursales locales.
69. SCCS tiene bloqueos implícitos, que se aplican al realizar el pago a través de edity se eliminan al crear un delta.
70. A través de varios medios, coloque el archivo (que será inmutable) en un directorio inmutable antes de realizar el vcheckin.
71. mv(1) o link(2) el archivo inmutable desde su directorio de origen inmutable a su directorio de destino inmutable antes de realizar el vcheckin.
72. A través de varios medios, copie el archivo inmutable desde su directorio de origen inmutable a su directorio de destino inmutable antes de realizar el vcheckin.
73. También se puede habilitar esto como una preferencia central en el panel de control del servidor de repositorio o en el archivo de configuración.
74. Requiere privilegios de administrador. Se puede "revertir" un cambio utilizando "cvs update –e –j @commitid –j "@<commitid"", pero la evidencia del cambio y la reversión permanecen en el historial.
75. Sí, use TortoiseCVS o WinCVS para confirmar el cambio en el destino y seleccionar qué archivos específicos conservar
76. bisect también está disponible para cvs, que debería funcionar con CVSNT
77. darcs opera sobre parches, no sobre revisiones; la selección selectiva consiste simplemente en extraer un parche determinado de un repositorio a otro siempre que se cumplan las dependencias.
78. El alijo de fósiles admite varios estantes con comentarios.
79. git stash es un sistema de almacenamiento de varios niveles, es posible almacenar varios grupos de cambios al mismo tiempo
80. Solo funciona en un repositorio local y solo en revisiones sin hijos. El comando de desaprobación podría ser una alternativa.
81. experimental en SVN 1.10 (notas de la versión)
82. Herramienta SVN Bisect svn-bisect
83. svn status enumera las diferencias entre la copia de trabajo y el repositorio, no las diferencias entre dos repositorios
84. hgweb para acceso a un único repositorio y hgwebdir para acceso a múltiples repositorios desde una única dirección HTTP

Referencias

1. "Lista de miembros del equipo CVS", Non-GNU Savannah , El Proyecto GNU
2. CVS Pro, Liebre de marzo
3. "Cómo comprar". perforce.com . Consultado el 18 de enero de 2018 .
4. Licencias y precios, PlasticSCM
5. "¿Qué es un sistema de control de versiones distribuido?". GitLab.
6. Jean-Michel Lemieux, Cuenta atrás para el próximo concierto de Rational Team: Parte II – Mejoras en el control de código fuente, Jazz Community, archivado desde el original el 10 de septiembre de 2015 , consultado el 28 de diciembre de 2010
7. Fundación de software Apache
8. Rational Synergy, IBM, 9 de noviembre de 2020
9. Sistema de gestión de configuración de Vesta, Sourceforge, 5 de junio de 2013
10. Sistema de gestión de configuración de Vesta, Vesta
11. IBM – Rational ClearCase – Estados Unidos, 9 de noviembre de 2020, archivado desde el original el 11 de noviembre de 2013
12. "Conjuntos de cambios". March Hare Software Ltd. Consultado el 8 de mayo de 2012 .
13. Descripción técnica de los fósiles
14. Política de hash de fósiles
15. Protocolo de servidor Git
16. "Git: un sistema de control de versiones distribuido, rápido y escalable". GitHub . 2 de noviembre de 2021.
17. "Copia archivada" (PDF) . Archivado desde el original (PDF) el 13 de noviembre de 2011. Consultado el 12 de enero de 2012 .{{cite web}}: CS1 maint: copia archivada como título ( enlace )
18. "Noticias de SCM: Kronos recurre a AccuRev para la gestión de configuración de software". AccuRev. 26 de abril de 2004. Archivado desde el original el 2 de febrero de 2014. Consultado el 26 de enero de 2014 .
19. "Rendimiento y escalabilidad mejorados para equipos distribuidos geográficamente y multiplataforma". AccuRev. 23 de septiembre de 2008. Archivado desde el original el 2 de febrero de 2014. Consultado el 26 de enero de 2014 .
20. "Las conversiones de fin de línea se admiten desde bzr 1.14". Doc.bazaar-vcs.org. Archivado desde el original el 13 de abril de 2009. Consultado el 26 de enero de 2014 .
21. Política de soporte para idiomas nacionales y ClearCase de IBM Support
22. Con la extensión Largefiles en el núcleo desde Hg Rev.:2.0 (2011), la extensión remotefilelog (2014), la extensión fsmonitor en el núcleo desde Hg Rev.:3.8 (2016) y la extensión experimental sparse en el núcleo desde Hg Rev.:4.3 (2017).
23. [4] Archivado el 10 de febrero de 2014 en Wayback Machine desde la Guía del usuario de Perforce
24. [5] Archivado el 9 de febrero de 2014 en Wayback Machine desde la Guía del usuario de Perforce
25. "Base de conocimientos públicos de Perforce: página principal". Perforce.com. Archivado desde el original el 14 de agosto de 2007. Consultado el 26 de enero de 2014 .
26. "Base de conocimientos de Perforce: internacionalización y localización". Kb.perforce.com. 21 de octubre de 2010. Archivado desde el original el 8 de febrero de 2012. Consultado el 26 de enero de 2014 .
27. "Base de conocimientos de Perforce: internacionalización y localización". Kb.perforce.com. 21 de octubre de 2010. Archivado desde el original el 30 de enero de 2013. Consultado el 26 de enero de 2014 .
28. [6] – Lanzamientos de Seapine Software Surround SCM 2009
29. "GitCentric | AccuRevGit para la empresa". Accurev.com. Archivado desde el original el 17 de octubre de 2012. Consultado el 26 de enero de 2014 .
30. "Complemento de palabras clave de Bazaar". Wiki.bazaar.canonical.com. 5 de septiembre de 2005. Archivado desde el original el 1 de febrero de 2014. Consultado el 26 de enero de 2014 .
31. "Plugin interactivo de Bazaar". Launchpad.net. 7 de marzo de 2008. Consultado el 26 de enero de 2014 .
32. "Plugin Bazaar Externals". Launchpad.net. 9 de noviembre de 2009. Consultado el 26 de enero de 2014 .
33. "Ignorar operación de fusión para la extensión dada". 4 de marzo de 2010.
34. "bzr-svn". Launchpad.net. 8 de mayo de 2006. Consultado el 26 de enero de 2014 .
35. "bzr-git". Launchpad.net. 15 de julio de 2006. Consultado el 26 de enero de 2014 .
36. "bzr-hg". Launchpad.net. 13 de junio de 2006. Consultado el 26 de enero de 2014 .
37. IBM Rational ClearCase: Los diez mejores activadores de IBM DeveloperWorks
38. El manifiesto, formatos de archivos fósiles
39. "Importación y exportación de fósiles". Fossil-scm.org. 22 de enero de 2014. Archivado desde el original el 2 de febrero de 2014. Consultado el 26 de enero de 2014 .
40. "FossilHelp: importación"
41. "Página del manual de git-submodule(1)". Kernel.org. 15 de febrero de 2013. Consultado el 26 de enero de 2014 .
42. "Página del manual de git-read-tree(1)". kernel.org. 2014-08-24 . Consultado el 2014-10-24 .
43. "Página de extensión de palabras clave de Mercurial". Mercurial-scm.org . Consultado el 26 de enero de 2014 .
44. "Página de Mercurial RecordExtension". Mercurial-scm.org. 2013-08-27 . Consultado el 2014-01-26 .
45. "Subrepositorio – Mercurial". Mercurial-scm.org . Consultado el 22 de abril de 2016 .
46. Con la extensión dispersa incluida en el núcleo desde Hg Rev.:4.3.
47. "Extensión de marca de tiempo de Mercurial". Mercurial-scm.org. 24 de abril de 2012. Consultado el 26 de enero de 2014 .
48. "Configuración de la herramienta de combinación". Mercurial-scm.org. 2017-03-14 . Consultado el 2017-09-05 .
49. "página hgsubversion". Mercurial-scm.org. 28 de agosto de 2013. Consultado el 26 de enero de 2014 .
50. "Complemento Mercurial Hg-Git". Hg-git.github.com . Consultado el 26 de enero de 2014 .
51. "Página de Mercurial ConvertExtension". Mercurial-scm.org. 2013-11-29 . Consultado el 2014-01-26 .
52. "Mercurial: la guía definitiva: Apéndice: Migración a Mercurial"
53. "Guía del usuario de P4". Perforce . Consultado el 19 de enero de 2018 .
54. "Sustitución de palabras clave". Svnbook.red-bean.com . Consultado el 26 de enero de 2014 .
55. "Definiciones externas". Svnbook.red-bean.com . Consultado el 26 de enero de 2014 .
56. ^ El comando pulldarcs es interactivo y permite al usuario elegir qué parches aplicar (fusionar) en tiempo real
57. "Extensión de Mercurial Rebase". Mercurial-scm.org. 25 de octubre de 2012. Consultado el 23 de abril de 2014 .
58. "bug 6463 – enh: buscar en el repositorio" . Consultado el 8 de mayo de 2012 .
59. "Página de extensión de Mercurial Shelve". Mercurial-scm.org. 2013-11-07 . Consultado el 2014-01-26 .
60. "Página de extensión de la tira Mercurial". Mercurial-scm.org . Consultado el 11 de mayo de 2016 .
61. "comando injerto -core (desde Hg Rev.2.0)". Selenic.com . Consultado el 26 de enero de 2014 .
62. "Página de extensión de Mercurial Transplant". Mercurial-scm.org. 12 de mayo de 2012. Consultado el 26 de enero de 2014 .
63. "El corredor de Perforce". Perforce.com. Archivado desde el original el 16 de noviembre de 2013. Consultado el 26 de enero de 2014 .
64. "Base de conocimientos de Perforce: integraciones "Cherry Picking"". Kb.perforce.com. 1 de enero de 1990. Archivado desde el original el 9 de marzo de 2012. Consultado el 26 de enero de 2014 .
65. "Integraciones admitidas: integridad de PTC". Mks.com. 10 de septiembre de 2012. Archivado desde el original el 25 de julio de 2012. Consultado el 26 de enero de 2014 .
66. "La Chose: agencia web y fabricante de software - agence web et développement de logiciels". Archivado desde el original el 18 de junio de 2016 . Consultado el 20 de septiembre de 2006 .
67. Sistema de control de código fuente distribuido. Portal.acm.org. 18 de mayo de 1997. Págs. 98-107. ISBN 9783540630142. Recuperado el 26 de enero de 2014 .
68. Hacia un mejor SCM: Revlogs y Mercurial, presentado por Matt Mackall en el Simposio Linux de Ottawa, julio de 2006
69. "GCC: Acceso anónimo de solo lectura a Git" . Consultado el 24 de octubre de 2023 .
70. "Guía de GnuPG para hackers". 11 de marzo de 2021. Consultado el 24 de octubre de 2023 .
71. "Obtener y trabajar con el código fuente de Perl". dev.perl.org . Consultado el 26 de enero de 2014 .
72. "Configuración y compilación". Python.org . Consultado el 24 de octubre de 2023 .
73. "Idiota". MediosWiki . Consultado el 1 de agosto de 2012 .
74. "El repositorio Git más grande del planeta". 24 de mayo de 2017.
75. "PTC establece un nuevo estándar para la gestión de los ciclos de vida del desarrollo de hardware y software con MKS Integrity Acquisition – PTC Integrity". Mks.com. Archivado desde el original el 22 de julio de 2014. Consultado el 26 de enero de 2014 .
76. Rochkind, Marc J. (diciembre de 1975), "The Source Code Control System" (PDF) , IEEE Transactions on Software Engineering , vol. SE-1, núm. 4, pp. 364–370, doi :10.1109/tse.1975.6312866, S2CID  10006076, archivado desde el original (PDF) el 25 de mayo de 2011 , consultado el 31 de julio de 2014
77. http://minnie.tuhs.org/cgi-bin/utree.pl?file=PWB1/usr/news/pibs Anuncio del producto PWB UNIX
78. Compare el formato de archivo SCCS 4 con el formato de archivo SCCS 5.0 Archivado 2014-08-19 en Wayback Machine (como página de manual sccsfile(4) en "Copia archivada". Archivado desde el original el 2014-08-19 . Consultado el 2014-08-17 .{{cite web}}: CS1 maint: copia archivada como título ( enlace )
79. Equipo de estrellas®