Articulo de referencia

Comparación de software de control de versiones

Las siguientes tablas describen los atributos de los sistemas de control de versiones y de gestión de configuración de software (SCM) más destacados , que pueden utilizarse para...

Las siguientes tablas describen los atributos de los sistemas de control de versiones y de gestión de configuración de software (SCM) más destacados , que pueden utilizarse para comparar y contrastar los distintos sistemas.

Para software SCM no apto para código fuente , consulte la 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, entre los que se incluyen:

  • Modelo de repositorio, la relación entre copias del repositorio de código fuente
    • En la arquitectura 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 del árbol del proyecto. Los cambios en una copia de trabajo deben confirmarse en el repositorio maestro antes de que se propaguen a otros usuarios.
    • En los sistemas distribuidos , los repositorios actúan como pares, y los usuarios suelen tener disponible un repositorio local con historial de versiones, además de sus copias de trabajo.
  • Modelo de concurrencia: cómo se gestionan los cambios en la copia de trabajo para evitar que las ediciones simultáneas generen datos sin sentido en el repositorio.
    • Bloqueo : no se permiten cambios hasta que el usuario solicite y reciba un bloqueo exclusivo del archivo desde el repositorio maestro.
    • En la fusión , los usuarios pueden editar archivos libremente, pero se les informa de posibles conflictos al confirmar sus cambios en el repositorio. En ese caso, el sistema de control de versiones puede fusionar los cambios en ambos lados o dejar que el usuario decida cuando surjan conflictos . Los sistemas de control de versiones distribuidos suelen utilizar un modelo de fusión concurrente.

Información técnica

La siguiente tabla muestra los detalles técnicos de algunos programas de control de versiones muy 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 desarrolla la aplicación.
  • Método de almacenamiento : Describe la forma en que se almacenan los archivos en el repositorio. Una instantánea indica que uno o más archivos confirmados se almacenan en su totalidad, generalmente comprimidos. Un conjunto de cambios , en este contexto, indica que uno o más archivos confirmados se almacenan como una diferencia entre la versión anterior y la siguiente.
  • Alcance del cambio : Describe si los cambios se registran para archivos individualeso 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 usaridentificadores 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 conjuntos de cambios, que pueden describir modificaciones 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 : Indica el tamaño del código fuente en megabytes.

Características

La siguiente tabla clasifica algunos programas informáticos 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.
  • Admite el formato de datos de Git : puede trabajar de forma nativa conlos formatos de repositorio de Git.
  • Confirmaciones atómicas : se refiere a la garantía de que se realizarán todos los cambios o de que no se realizará ningún cambio.
  • 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 archivos : describe si un sistema puede combinar los cambios realizados en un archivo de una rama con el mismo archivo que ha sido renombrado en otra rama (o viceversa). Si el mismo archivo ha sido renombrado en ambas ramas, existe un conflicto de nombres que el usuario debe resolver.
  • Enlaces simbólicos : describe si un sistema permite el control de versiones de enlaces simbólicos, al igual que con los archivos regulares. Algunos consideran que el control de versiones de enlaces simbólicos es una ventaja, mientras que otros lo consideran una vulnerabilidad de seguridad (por ejemplo, un enlace simbólico a /etc/passwd). Los enlaces simbólicos solo son compatibles con ciertas plataformas, dependiendo del software.
  • Ganchos previos/posteriores al evento : indican la capacidad de activar comandos antes o después de que se produzca una acción, como una confirmación.
  • Revisiones firmadas : se refiere a la firma digital integrada de revisiones, en un formato comoOpenPGP.
  • Seguimiento de fusiones : 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 de los archivos de texto para que coincidan con el estilo de fin de línea del sistema operativo en el que se utiliza. El nivel de control varía. Subversion, por ejemplo, se puede configurar para gestionar 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 es compatible con varios entornos lingüísticos y sistemas operativos.
  • Compatibilidad con nombres de archivo Unicode : indica si el software admite interoperabilidad entre sistemas de archivos que utilizan diferentes codificaciones de caracteres .
  • Admite repositorios grandes : ¿Puede el sistema gestionar eficazmente repositorios de aproximadamente un gigabyte o más?

Funciones avanzadas

A continuación se presentan algunas de las características y capacidades más avanzadas disponibles en los sistemas de control de versiones más destacados:

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 (fragmentos de parche) que pasan a formar 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 : incrustación de repositorios externos en el árbol de origen.
  • Extracción/clonación parcial : posibilidad de extraer o clonar únicamente un subdirectorio específico de un repositorio.
  • Permisos : registra los bits de permisos de archivo en el historial de revisiones.
  • Conservación de la marca de tiempo : sobrescribe elde última modificacióncon la hora de confirmación al realizar la extracción.
  • Herramienta de fusión automática personalizada : la fusión automática puede intentarse con cualquier herramienta que elija el usuario (idealmente, configurable para cada archivo).
  • Formatos compatibles : lectura/escritura o solo lectura (conversión, posiblemente repetida).
  • Caché de compilación compartida de objetos derivados : la capacidad de sustituir automáticamente (guiño) los objetos derivados que fueron compilados por otros clientes confederados que comparten exactamente las mismas dependencias, en lugar de recompilarlos localmente.

Comandos básicos

La siguiente tabla proporciona información adicional sobre los comandos disponibles en los sistemas de control de versiones más importantes.

Explicación de la tabla

  • Inicialización del repositorio : Crea un nuevo repositorio vacío (es decir, una base de datos de control de versiones).
  • clonar : crea una instancia idéntica de un repositorio (en una transacción segura).
  • pull : Descarga revisiones de un repositorio remoto a un repositorio local.
  • push : Subir 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 : Actualiza los archivos en una copia de trabajo con la última versión de un repositorio.
  • Bloquear : Bloquea los archivos de un repositorio para que otros usuarios no puedan modificarlos.
  • Agregar : Marcar los archivos especificados para que se agreguen al repositorio en el próximo commit.
  • remove : Marca los archivos especificados para que se eliminen en la próxima confirmación (nota: mantiene un historial de revisiones coherente de antes y después de la eliminación).
  • mover : Marca los archivos especificados para que se muevan a una nueva ubicación en la próxima confirmación.
  • Copiar : Marca los archivos especificados para que se copien en la siguiente confirmación.
  • fusionar : Aplicar las diferencias entre dos fuentes a una ruta de copia de trabajo
  • commit : Registra los 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 : Reenviar confirmaciones locales al encabezado actualizado del repositorio remoto
  • Nota: Los comandos en rectángulos verdes que no están entre corchetes [ ] corresponden a la línea de comandos interactiva. El texto entre corchetes [ ] explica dónde encontrar la funcionalidad equivalente.

Comandos avanzados

La siguiente tabla muestra los comandos utilizados para ejecutar tareas comunes en sistemas de control de versiones destacados.

Explicación de la tabla

  • Alias ​​de comandos : cree alias personalizados para comandos específicos o combinaciones de los mismos.
  • Bloquear/desbloquear : bloquear exclusivamente un archivo para impedir que otros lo editen.
  • Guardar/desguardar : apartar temporalmente parte o la totalidad de los cambios en el directorio de trabajo.
  • Revertir : eliminar un parche/revisión del historial
  • Selección de revisiones : mover solo algunas revisiones de una rama a otra (en lugar de fusionar las ramas).
  • Bisect : búsqueda binaria en el historial de origen para encontrar un cambio que introdujo o corrigió una regresión.
  • Entrada/salida : consulta las diferencias entre el repositorio local y uno remoto (los parches que se obtendrían/enviarían en una operación 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 [ ] corresponden a la interfaz interactiva de línea de comandos. El texto entre corchetes [ ] explica dónde encontrar la funcionalidad equivalente.

Interfaces de usuario

La siguiente tabla muestra las especificaciones de las interfaces web, gráficas de usuario (GUI) y de entornos de desarrollo integrados (IDE) para los sistemas de control de versiones más importantes.

Explicación de la tabla

  • Software : El nombre de la aplicación que se describe.
  • Interfaz web : Indica si la aplicación de software incluye una interfaz web. Una interfaz web podría permitir que el software publique datos de diagnóstico en un sitio web, o incluso permitir el control remoto de la aplicación.
  • Interfaces gráficas de usuario (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 ventanas de aplicación, en lugar de acceder a ella escribiendo comandos en la línea de comandos, como en una interfaz de DOS.
  • Complementos : las funciones están disponibles a través de un entorno de desarrollo integrado . La función mínima debe ser listar el estado de revisión de un archivo y registrar/extraer archivos.

Historia y adopción

La siguiente tabla proporciona información histórica sobre diversos sistemas 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 destacados : es una lista de proyectos conocidos que utilizan el software como su sistema principal de control de versiones, excluyendo el software en sí, seguida de un enlace a la lista completa si está disponible.

Véase también

Notas

  1. En ClearCase, se puede configurar un disparador para permitir el modelo de bloqueo, algo que se hace en muchos sitios. Sin embargo, el desarrollo en ClearCase suele realizarse en ramas privadas donde cada desarrollador tiene su propia rama, por lo que el modelo de concurrencia de bloqueo frente a fusión no tiene tanta importancia. El código se fusiona de nuevo con la rama principal una vez que el desarrollador está listo para entregarlo al proyecto.
  2. RTC no es un sistema de control de revisiones distribuido; pero tiene algunas características distribuidas que se pueden configurar.
  3. Existen varias bifurcaciones del código fuente original de Unix, pero solo una de ellas recibe mantenimiento activo.
  4. Si bien es posible que varios usuarios editen la misma versión de un archivo simultáneamente, solo uno de ellos puede guardar los cambios.
  5. Si bien algunas bifurcaciones de SCCS son software libre, otras permanecen cerradas como parte de distribuciones comerciales de Unix.
  6. En Subversion, un atributo de archivo habilita el modelo de bloqueo para cada archivo individualmente. 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 de paciencia , utilizado en la resolución de fusiones, que está escrito directamente enlenguaje C.
  8. Un paquete de Bazaar es una diferencia resumida, con suficiente información adicional para preservar el historial.
  9. Instantáneas con archivos binarios. Se está considerando la posibilidad de incluir 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 a un repositorio; pueden diferir de un repositorio a otro dependiendo del orden en 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 un manifiesto. Sin embargo, los manifiestos son estructuras heredadas; ya no se almacenan en la base de datos ni se reconstruyen sobre la marcha si es necesario. El trabajo real ahora se realiza en las listas de cambios, que son estructuras híbridas de instantáneas y conjuntos de cambios.
  13. Los gemelos malvados son comunes. Gemelos malvados en SCM, no en Hollywood. Archivado el 16/10/2013 en Wayback Machine.
  14. Se puede habilitar la confirmación atómica para confirmaciones individuales . Notas de la versión de ClearCase 7.1.1 .
  15. Ver preguntas frecuentes
  16. Cada parche de darcs tiene un identificador único, lo que hace imposible fusionar dos veces el mismo parche en un repositorio (sin modificar destructivamente el historial usando comandos "inseguros").
  17. Aunque almacena (y muestra por defecto) nombres de archivo de 8 bits. Consulte las preguntas frecuentes.
  18. Uso de atributos de revisión de elementos ( Demostración "Trabajando con elementos", que cubre 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 están disponibles en inglés, aunque el software está certificado para funcionar correctamente en varios sistemas operativos de diferentes idiomas.
  20. Controlado por la configuración 'crnl-glob' ()
  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 archivos fuente se detectan a posteriori, si el contenido del archivo no cambia drásticamente.
  22. Desde git-1.7.9 (ver notas de la versión. Enlace obsoleto archivado el 15/04/2013 en archive.today ). Las versiones anteriores no firman confirmaciones, solo etiquetas (ver la opción -s en la página del manual de git-tag(1) ).
  23. Los nombres de archivo 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 las Ideas de SoC 2012 .
  25. Los paquetes de cambio con integridad habilitada proporcionan un flujo de trabajo completo y firmas digitales que cumplen con la Parte 11 del Título 21 del Código de Regulaciones Federales (21 CFR Parte 11) contra el elemento que controla el paquete de cambio.
  26. En 2009 SP5 se añadió una función para fusionar las rutas de desarrollo infantil.
  27. Mercurial incluye internacionalización para más de 10 idiomas desde 2017.
  28. La compatibilidad depende del sistema operativo anfitrión y es compatible con Unix, pero no con Windows, debido a la falta de compatibilidad con el sistema anfitrión. Ver
  29. Se podría hacer mediante ganchos a nivel de usuario.
  30. Perforce controlará las versiones de los enlaces simbólicos, pero no reconocerá sus propias vistas controladas por versiones (árboles de archivos locales) si se 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 la operación. http://jazz.net/library/article/292
  32. Si bien el código fuente de SCCS se ha escrito para admitir la internacionalización, solo existen textos de mensajes en inglés.
  33. StarTeam admite confirmaciones atómicas desde la versión 2006.
  34. Subversion puede mover un archivo y conservar su historial, solo si el destino del movimiento se encuentra en el mismo repositorio de Subversion que el origen. Los movimientos entre repositorios requieren herramientas de terceros.
  35. Desde SVN 1.8, 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. Novedad en SVN 1.5 < http://subversion.apache.org/docs/release-notes/1.5.html#merge-tracking >. Una herramienta independiente "svnmerge" <> Proporciona seguimiento de fusión 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 "tags". Debido a esto, incluso las etiquetas tienen versiones. Consulte http://svnbook.red-bean.com/nightly/en/svn.branchmerge.tags.html para obtener más información. La razón del 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 pueda usarse en lugar de cualquier identificador de revisión donde el usuario deba ingresar uno. Esta columna carecería de sentido si la definición se flexibilizara lo suficiente como para abarcar el enfoque de Subversion, ya que todos los sistemas de control de versiones admiten ramificaciones 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 renombrar; no se hace referencia al nombre anterior.
  41. Aún no implementado
  42. No se puede deshabilitar en vistas dinámicas.
  43. Usando un alias del archivo CVSROOT/modules.
  44. CVS registra el bit de ejecución cuando se agrega un archivo, pero no permite cambiarlo posteriormente.
  45. Esta es una característica de la interfaz gráfica de usuario compatible con TortoiseCVS y WinCVS, los cuales incluyen/usan CVSNT.
  46. Igual que CVS, además de la posibilidad de tener repositorios replicados, incluidos repositorios "en la sombra".
  47. Utilice el nombre del módulo/directorio o un alias creado mediante el archivo de administración CVSROOT/modules o CVSROOT/modules2.
  48. CVSNT admite esto cuando la herramienta de compilación/creación utilizada también lo admite.
  49. Darcs puede realizar extracciones dispersas desde puntos de control explícitos en repositorios darcs-1, pero no desde repositorios darcs-2.
  50. Darcs puede detectar automáticamente los scripts #! y hacerlos ejecutables al realizar el checkout.
  51. Uso de la funcionalidad de subproyectos ( Portafolio de documentación | Guía del usuario | Relacionar un proyecto o flujo con otros objetos ).
  52. Los procesos de pago pueden anidarse con "fossil open –nested"
  53. Las preguntas frecuentes de Git afirman que la expansión de palabras clave no es algo bueno.
  54. agregar -i y agregar -p , ver la página del manual de git-add(1)
  55. Las preguntas frecuentes de Git explican por qué se considera perjudicial conservar la hora 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. Mediante herramientas de terceros como Tortoise SVN .
  58. SVN no conserva las fechas de modificación de los archivos. A petición del cliente, puede restaurar la fecha de confirmación como fecha de última modificación. Desactivado por defecto.
  59. El tipo MIME del archivo debe detectarse como un tipo MIME "legible para humanos", incluso si la herramienta de fusión puede trabajar con archivos no legibles para humanos.
  60. Rama independiente , archivada desde la original el 4 de marzo de 2016 , recuperada el 6 de noviembre de 2014.
  61. Repositorio compartido , archivado desde el original el 4 de marzo de 2016 , recuperado el 6 de noviembre de 2014.
  62. Rama independiente , archivada desde la original el 4 de marzo de 2016 , recuperada el 6 de noviembre de 2014.
  63. Pago pesado y pago ligero , archivado del original el 30/06/2016 , recuperado el 06/11/2014.
  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 electrónico pero puede enviarlo a un archivo en su lugar.
  67. Las copias se detectan a posteriori, al igual que los cambios de nombre.
  68. Los marcadores mercuriales son similares a las sucursales locales.
  69. SCCS tiene bloqueos implícitos, aplicados al extraer medianteedit, eliminados al crear un delta.
  70. Mediante cualquiera de los diversos medios, coloque el archivo (que será inmutable) en un directorio inmutable antes de vcheckin.
  71. mv(1) o link(2) el archivo inmutable desde su directorio inmutable de origen a su directorio inmutable de destino antes de vcheckin.
  72. Mediante cualquiera de los diversos medios, copie el archivo inmutable desde su directorio inmutable de origen a su directorio inmutable de destino antes de vcheckin.
  73. También se puede habilitar como una preferencia central en el panel de control del servidor del repositorio o en el archivo de configuración.
  74. Requiere privilegios de administrador. Se puede "deshacer" un cambio usando 'cvs update -e -j @commitid -j "@<commitid"' pero el cambio y la evidencia de la reversión permanecen en el historial.
  75. Sí, utilice TortoiseCVS o WinCVS para confirmar el cambio en el destino y seleccione qué archivos específicos desea conservar.
  76. bisect también está disponible para cvs, que debería funcionar con CVSNT.
  77. darcs opera con parches, no con revisiones; el cherrypicking 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 múltiples estantes con comentarios.
  79. git stash es un estante multinivel, es posible almacenar varios grupos de cambios al mismo tiempo.
  80. Solo funciona en un repositorio local y solo en revisiones sin subrevisiones. El comando 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 muestra las diferencias entre la copia de trabajo y el repositorio, no las diferencias entre dos repositorios.
  84. hgweb para acceso a un solo repositorio y hgwebdir para acceso a múltiples repositorios desde una única dirección HTTP.

Referencias

  1. "Lista de miembros del equipo CVS" , Savannah no GNU , El Proyecto GNU
  2. CVS Pro , Liebre de marzo
  3. "Cómo comprar" . perforce.com . Consultado el 18 de enero de 2018 .
  4. "¿Qué es un sistema de control de versiones distribuido?" . GitLab.
  5. Jean-Michel Lemieux, Cuenta atrás para el próximo concierto de Rational Team: Parte II – Mejoras en el control de versiones , Jazz Community, archivado del original el 10/09/2015 , consultado el 28/12/2010.
  6. Rational Synergy , IBM, 9 de noviembre de 2020
  7. Fundación de Software Apache
  8. Licencias y precios , PlasticSCM
  9. IBM – Rational ClearCase – Estados Unidos , 9 de noviembre de 2020, archivado del original el 11 de noviembre de 2013
  10. "Conjuntos de cambios" . March Hare Software Ltd. Consultado el 8 de mayo de 2012 .
  11. Descripción general técnica de los fósiles
  12. Política de hash de Fossil
  13. "Git 2.51 lanzado con optimizaciones de rendimiento y SHA-256 como función hash predeterminada – Blog de Cyber ​​Web Spider – Noticias" . 20 de agosto de 2025.
  14. Protocolo de servidor Git
  15. "Git: sistema de control de versiones rápido, escalable y distribuido" . GitHub . 2 de noviembre de 2021.
  16. "Copia archivada" (PDF) . Archivado del original (PDF) el 13-11-2011 . Recuperado el 12-01-2012 .{{cite web}}: CS1 mantenimiento: copia archivada como título ( enlace )
  17. "Noticias de SCM: Kronos recurre a AccuRev para la gestión de la configuración del software" . AccuRev. 26 de abril de 2004. Archivado del original el 2 de febrero de 2014. Consultado el 26 de enero de 2014 .
  18. "Rendimiento y escalabilidad mejorados para equipos distribuidos geográficamente en múltiples plataformas" . AccuRev. 23 de septiembre de 2008. Archivado del original el 2 de febrero de 2014. Consultado el 26 de enero de 2014 .
  19. "Las conversiones EOL son compatibles desde bzr 1.14" . Doc.bazaar-vcs.org. Archivado del original el 13 de abril de 2009. Consultado el 26 de enero de 2014 .
  20. Política de soporte para idiomas nacionales y ClearCase de IBM Support
  21. "Fósil: Ganchos" .
  22. "Fósil: Fósil contra Git" .
  23. ^ "GitExtension - Mercurial" .
  24. https://foss.heptapod.net/mercurial/mercurial-devel/-/tree/branch/default/hgext/git
  25. 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) .
  26. Archivado el 10 de febrero de 2014 en Wayback Machine desde la Guía del usuario de Perforce .
  27. Archivado el 9 de febrero de 2014 en Wayback Machine desde la Guía del usuario de Perforce .
  28. "Base de conocimientos públicos de Perforce - Inicio" . Perforce.com. Archivado del original el 14 de agosto de 2007. Consultado el 26 de enero de 2014 .
  29. "Base de conocimientos de Perforce: internacionalización y localización" . Kb.perforce.com. 21/10/2010. Archivado del original el 08/02/2012 . Consultado el 26/01/2014 .
  30. "Base de conocimientos de Perforce: internacionalización y localización" . Kb.perforce.com. 21/10/2010. Archivado del original el 30/01/2013 . Consultado el 26/01/2014 .
  31. – Seapine Software lanza Surround SCM 2009
  32. "GitCentric | AccuRevGit para la empresa" . Accurev.com. Archivado del original el 17 de octubre de 2012. Consultado el 26 de enero de 2014 .
  33. "Complemento de palabras clave de Bazaar" . Wiki.bazaar.canonical.com. 5 de septiembre de 2005. Archivado del original el 1 de febrero de 2014. Consultado el 26 de enero de 2014 .
  34. "Complemento interactivo Bazaar" . Launchpad.net. 7 de marzo de 2008. Consultado el 26 de enero de 2014 .
  35. "Complemento Bazaar Externals" . Launchpad.net. 9 de noviembre de 2009. Consultado el 26 de enero de 2014 .
  36. "Ignorar la operación de fusión para la extensión dada" . 4 de marzo de 2010.
  37. "bzr-svn" . Launchpad.net. 8 de mayo de 2006. Consultado el 26 de enero de 2014 .
  38. "bzr-git" . Launchpad.net. 15 de julio de 2006. Consultado el 26 de enero de 2014 .
  39. "bzr-hg" . Launchpad.net. 13 de junio de 2006. Consultado el 26 de enero de 2014 .
  40. IBM Rational ClearCase: Los diez mejores disparadores de IBM DeveloperWorks
  41. El manifiesto , formatos de archivo Fossil
  42. "Importación y exportación de fósiles" . Fossil-scm.org. 22 de enero de 2014. Archivado del original el 2 de febrero de 2014. Consultado el 26 de enero de 2014 .
  43. "FossilHelp: importar"
  44. "Página del manual de git-submodule(1)" . Kernel.org. 15 de febrero de 2013. Consultado el 26 de enero de 2014 .
  45. "Página del manual de git-read-tree(1)" . kernel.org. 24 de agosto de 2014. Consultado el 24 de octubre de 2014 .
  46. "Página de extensión de palabras clave de Mercurial" . Mercurial-scm.org . Consultado el 26 de enero de 2014 .
  47. "Página de extensión de registro de Mercurial" . Mercurial-scm.org. 27 de agosto de 2013. Consultado el 26 de enero de 2014 .
  48. "Subrepositorio – Mercurial" . Mercurial-scm.org . Consultado el 22 de abril de 2016 .
  49. Con la extensión dispersa incluida en el núcleo desde Hg Rev.:4.3 .
  50. "Extensión de marca de tiempo de Mercurial" . Mercurial-scm.org. 24 de abril de 2012. Consultado el 26 de enero de 2014 .
  51. "Configuración de la herramienta de fusión" . Mercurial-scm.org. 14 de marzo de 2017. Consultado el 5 de septiembre de 2017 .
  52. "página de hgsubversion" . Mercurial-scm.org. 28 de agosto de 2013. Consultado el 26 de enero de 2014 .
  53. "Complemento Mercurial de Hg-Git" . Hg-git.github.com . Consultado el 26 de enero de 2014 .
  54. "Página de Mercurial ConvertExtension" . Mercurial-scm.org. 29/11/2013 . Consultado el 26/01/2014 .
  55. "Mercurial: la guía definitiva: Apéndice: Migración a Mercurial"
  56. 1 2 3 "Guía del usuario de P4" . Perforce . Consultado el 19 de enero de 2018 .
  57. "Sustitución de palabras clave" . Svnbook.red-bean.com . Consultado el 26 de enero de 2014 .
  58. "Definiciones externas" . Svnbook.red-bean.com . Consultado el 26 de enero de 2014 .
  59. 1 2 El comando pull predeterminado de darcses interactivo, lo que permite al usuario elegir qué parches aplicar (fusionar) en tiempo real.
  60. "Extensión de rebase de Mercurial" . Mercurial-scm.org. 25/10/2012 . Consultado el 23/04/2014 .
  61. "bug 6463 - enh: search repository" . Consultado el 8 de mayo de 2012 .
  62. "Página de extensión de Mercurial Shelve" . Mercurial-scm.org. 7 de noviembre de 2013. Consultado el 26 de enero de 2014 .
  63. "Página de extensión de la tira de mercurio" . Mercurial-scm.org . Consultado el 11 de mayo de 2016 .
  64. "comando graft -core (desde Hg Rev.2.0)" . Selenic.com . Consultado el 26 de enero de 2014 .
  65. "Página de extensión de trasplante de mercurio" . Mercurial-scm.org. 12 de mayo de 2012. Consultado el 26 de enero de 2014 .
  66. "The Perforce Broker" . Perforce.com. Archivado del original el 16 de noviembre de 2013. Consultado el 26 de enero de 2014 .
  67. "Base de conocimientos de Perforce: Integraciones de selección selectiva" . Kb.perforce.com. 1990-01-01. Archivado del original el 2012-03-09 . Consultado el 2014-01-26 .
  68. "Integraciones compatibles – PTC Integrity" . Mks.com. 10 de septiembre de 2012. Archivado del original el 25 de julio de 2012. Consultado el 26 de enero de 2014 .
  69. «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 . 
  70. Sistema de control de versiones distribuido . Portal.acm.org. 18 de mayo de 1997. págs. 98–107 . ISBN  9783540630142. Consultado el 26 de enero de 2014 .
  71. 1 2 Hacia un mejor SCM: Revlogs y Mercurial , presentado por Matt Mackall en el Simposio Linux de Ottawa, julio de 2006
  72. "GCC: Acceso anónimo de solo lectura a Git" . Consultado el 24 de octubre de 2023 .
  73. "Guía de GnuPG para hackers" . 11 de marzo de 2021. Consultado el 24 de octubre de 2023 .
  74. "Obtención y uso del código fuente de Perl" . dev.perl.org . Consultado el 26 de enero de 2014 .
  75. "Configuración y compilación" . Python.org . Consultado el 24 de octubre de 2023 .
  76. «Git» . MediosWiki . Consultado el 1 de agosto de 2012 .
  77. "El repositorio Git más grande del planeta" . 24 de mayo de 2017.
  78. "PTC establece un nuevo estándar para la gestión de los ciclos de vida del desarrollo de hardware y software con la adquisición de MKS Integrity – PTC Integrity" . Mks.com. Archivado del original el 22 de julio de 2014. Consultado el 26 de enero de 2014 .
  79. "Algunos proyectos que usan Mercurial" , Mercurial (wiki), Mercurial-scm.org.
  80. Rochkind, Marc J. (diciembre de 1975), "The Source Code Control System" (PDF) , IEEE Transactions on Software Engineering , vol. SE-1, n.º 4, págs. 364–370 , Bibcode : 1975ITSEn...1..364R , doi : 10.1109/tse.1975.6312866 , S2CID 10006076 , archivado del original (PDF) el 25 de mayo de 2011 , recuperado el 31 de julio de 2014    
  81. http://minnie.tuhs.org/cgi-bin/utree.pl?file=PWB1/usr/news/pibs Anuncio del producto PWB UNIX
  82. Compare el formato de archivo SCCS 4 con elformato de archivo SCCS 5.0 Archivado el 19-08-2014 en Wayback Machine (como página de manual sccsfile(4) en "Copia archivada") . Archivado del original el 19-08-2014 . Recuperado el 17-08-2014 .{{cite web}}: CS1 mantenimiento: copia archivada como título ( enlace )
  83. Starteam®
Obtenido de " https://en.wikipedia.org/w/index.php?title=Comparison_of_version-control_software&oldid=1360129983 "