Articulo de referencia

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 compar...

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 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 (fragmentos de parches) 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ía los commits 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 o una 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

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. ^ Snapshots with binary files. It's discussed to have binary changesets in future (darcs 3)
  10. ^ 4 MB of which are sqlite3.c
  11. ^ Mercurial revision numbers are local to a repository; they can differ from repository to repository depending on in which order merges are performed.
  12. ^ A Monotone's revisions represent changesets and its manifests represent snapshots, each revision is linked to some manifest. But manifests are legacy constructs, they aren't kept in the database anymore and reconstructed on the fly if needed. The real work now happen in rosters which are hybrid snapshot/changeset structures.
  13. ^ Evil twins are common.Evil Twins in SCM, Not Hollywood Archived 2013-10-16 at the Wayback Machine
  14. ^ Atomic commit can be enabled for individual checkin's ClearCase 7.1.1 release notes.
  15. ^ See FAQ
  16. ^ darcs' patches each bear a unique identifier, impossible to merge twice the same patch in a repository (without destructively modifying history using "unsafe" commands).
  17. ^ Although it stores (and shows by default) 8-bit filename. See FAQ
  18. ^ Using Item Revision Attributes ("Working with Items" demo, covering user define attributes Archived 2016-03-04 at the Wayback Machine).
  19. ^ In the sense that its messages and graphic interfaces have English only localization, though the software is certified running fine on various language operating systems.
  20. ^ Controlled by the 'crnl-glob' setting ([1])
  21. ^ Git does not explicitly track renames, because by design it does not track individual files. Renames and split of source files are detected after the fact, if the file content does not change dramatically.
  22. ^ Since git-1.7.9 (see release notes Archived 2013-04-15 at archive.today). Older versions do not sign commits, only tags (see the -s option in git-tag(1) Manual page)
  23. ^ UTF-8 filenames are supported as of version 1.7.10 (MSysGit release notes).
  24. ^ Git has some issues with very large repositories. See Section Better big-file support and Section Designing a faster index format in SoC 2012 Ideas.
  25. ^ Integrity enabled change packages provide complete workflow and 21 CFR Part 11 compliant digital signatures against the item controlling the change package.
  26. ^ 2009 SP5 added a feature to merge child development paths.
  27. ^ Mercurial includes internationalization for more than 10 languages as of 2017.
  28. ^ Support depends upon host OS and is well supported under Unix, but not Windows OSs, due to lack of host support. See [2]
  29. ^ It could be done via user level hooks
  30. ^ Perforce will version-control symbolic links themselves, but will not recognise its own version-controlled views (local file trees), if you access them via symbolic links.
  31. ^ Through the process behaviour components: Operation advisors and Operation participants. http://jazz.net/library/article/292
  32. ^ While the source code of SCCS has been written to support internationalisation, only English message texts exist.
  33. ^ StarTeam supports atomic commits as of version 2006
  34. ^ Subversion can move a file and conserve its history, if and only if the target of the move is in the same Subversion repository as the source. Cross-repository moves require third-party tools.
  35. ^ Since SVN 1.8 subversion supports improved move-tracking on the client side. On the server-side it's not supported yet.
  36. ^ "Changeset Signing". Apache Subversion Mailing Lists. Retrieved 2016-08-05.
  37. ^ New to SVN 1.5 <http://subversion.apache.org/docs/release-notes/1.5.html#merge-tracking>. A separate tool "svnmerge" <[3]> provides merge tracking for older versions.
  38. ^ In Subversion, tags are a special case of the more generic "cheap copy" concept of Subversion. Per convention, a tag is a copy into a directory named "tags". Because of this, even tags are versioned. See http://svnbook.red-bean.com/nightly/en/svn.branchmerge.tags.html for more information. The reason for partial support in the table is because Subversion's emulation of tags in this manner does not meet the requirement that the tag name can be used in place of any revision identifier wherever the user may be required to enter one. This column would be meaningless if the definition were to be loosened enough to encompass Subversion's approach as every version control system supports branching and would therefore support tags as well.
  39. ^ in Asian releases (v6.6a to v7.1a) and since version 7.2 in general
  40. ^ Version change history is removed upon rename; old name not referenced.
  41. ^ not implemented yet
  42. ^ Can not be disabled in dynamic views.
  43. ^ Using alias of the CVSROOT/modules file.
  44. ^ CVS records executable bit when a file is added, but does not allow changing it later on.
  45. ^ This is a GUI feature supported by TortoiseCVS and WinCVS both of which include/use CVSNT.
  46. ^ Same as CVS, plus also the ability to have replicated repositories including 'shadow' repositories.
  47. ^ Use the module/directory name or an alias created using CVSROOT/modules or CVSROOT/modules2 administration file.
  48. ^ CVSNT supports this when the make/build tool used also supports it.
  49. ^ Darcs can do sparse checkouts from explicit checkpoints on darcs-1 repositories, but not from darcs-2 ones[citation needed]
  50. ^ Darcs can automatically detect #! scripts and make them executable on checkout.
  51. ^ Using Sub Project functionality (Documentation Portfolio | User's Guide | Relating a Project or Stream to Other Objects).
  52. ^ Checkouts can be nested with "fossil open –nested"
  53. ^ The Git FAQ states that keyword expansion is not a good thing
  54. ^ add -i and add -p, see git-add(1) Manual Page
  55. ^ The Git FAQ explains why preserving modification time is considered harmful
  56. ^ Configurable on server as a Project Option and on the client as a User Option.
  57. ^ Through third-party tools such as Tortoise SVN.
  58. ^ SVN can not preserve file modification times. On request by the client, it can restore check-in time as last-modified time. Disabled by default.
  59. ^ MIME type of the file must be detected as a "human-readable" MIME type, even if the merge tool can work with non-human-readable files
  60. ^ Standalone Branch, archived from the original on 2016-03-04, retrieved 2014-11-06
  61. ^ Shared Repository, archived from the original on 2016-03-04, retrieved 2014-11-06
  62. ^ Standalone Branch, archived from the original on 2016-03-04, retrieved 2014-11-06
  63. ^ Heavyweight Checkout and Lightweight Checkout, archived from the original on 2016-06-30, retrieved 2014-11-06
  64. ^ rebase plugin
  65. ^ darcs doesn't have named branches, local or not, branching is handled solely through repository cloning
  66. ^ darcs send prepares a bundle of patches, defaults to sending it by mail but can send it to a file instead
  67. ^ copies are detected after the fact, much like renames
  68. ^ Mercurial Bookmarks are similar to local branches.
  69. ^ SCCS has implicit locks, applied when checking out via edit, removed when creating a delta.
  70. ^ Through any of various means, place (to-be-immutable) file in an immutable directory prior to vcheckin.
  71. ^ mv(1) or link(2) the immutable file from its origin immutable directory to its destination immutable directory prior to vcheckin.
  72. ^ Through any of various means, copy the immutable file from its origin immutable directory to its destination immutable directory prior to vcheckin.
  73. ^ One can also enable this as a central preference in the repository server control panel or configuration file.
  74. ^ Requires administrator privileges. One can 'roll back' a change using 'cvs update –e –j @commitid –j "@<commitid"' but the change and rollback evidence remain in the history.
  75. ^ yes – use TortoiseCVS or WinCVS to commit the change to the destination and select which specific files to keep
  76. ^ bisect is also available for cvs which should work with CVSNT
  77. ^ darcs operate on patches not revision, cherrypicking simply consists in pulling a given patch from one repository to another one as long as the dependencies are fulfilled
  78. ^ fossil stash supports multiple shelves with comments.
  79. ^ git stash is a multi-level shelve, it's possible to shelve several change groups at the same time
  80. ^ Only works on a local repository and only on revisions without children. The disapprove command might be an alternative.
  81. ^ experimental in SVN 1.10 (release notes)
  82. ^ SVN Bisect tool svn-bisect
  83. ^ svn status lists differences between working copy and repository, not differences between two repositories
  84. ^ hgweb for single-repository access and hgwebdir for multiple repository access from a single HTTP address

References

  1. ^ "CVS team member list", Non-GNU Savannah, The GNU Project
  2. ^ CVS Pro, March Hare
  3. ^ "How To Buy". perforce.com. Retrieved 2018-01-18.
  4. ^ Licesing and pricing, PlasticSCM
  5. ^ "What is a distributed version control system". GitLab.
  6. ^ Jean-Michel Lemieux, Countdown to the next Rational Team Concert: Part II – Source control enhancements, Jazz Community, archived from the original on 2015-09-10, retrieved 2010-12-28
  7. ^ Apache Software Foundation
  8. ^ Rational Synergy, IBM, 9 November 2020
  9. ^ Vesta Configuration Management System, Sourceforge, 5 June 2013
  10. ^ Vesta Configuration Management System, Vesta
  11. ^ IBM – Rational ClearCase – United States, 9 November 2020, archived from the original on November 11, 2013
  12. ^ "Changesets". March Hare Software Ltd. Retrieved 8 May 2012.
  13. ^ Fossil Technical Overview
  14. ^ Fossil Hash Policy
  15. ^ Git Server Protocol
  16. ^ "Git - fast, scalable, distributed revision control system". GitHub. 2 November 2021.
  17. ^ "Archived copy" (PDF). Archived from the original (PDF) on 2011-11-13. Retrieved 2012-01-12.{{cite web}}: CS1 maint: archived copy as title (link)
  18. ^ "SCM News – Kronos Turns to AccuRev for Software Configuration Management". AccuRev. 2004-04-26. Archived from the original on 2014-02-02. Retrieved 2014-01-26.
  19. ^ "Enhanced Performance and Scalability for Cross-Platform Geographically Distributed Teams". AccuRev. 2008-09-23. Archived from the original on 2014-02-02. Retrieved 2014-01-26.
  20. ^ "EOL conversions are supported since bzr 1.14". Doc.bazaar-vcs.org. Archived from the original on 2009-04-13. Retrieved 2014-01-26.
  21. ^ Support Policy for National Languages and ClearCase from IBM Support
  22. ^ With the Largefiles Extension in core since Hg Rev.:2.0 (2011), the remotefilelog extension (2014), the fsmonitor extension in core since Hg Rev.:3.8 (2016) and the experimental sparse extension in core since Hg Rev.:4.3 (2017).
  23. ^ [4] Archived 2014-02-10 at the Wayback Machine from the Perforce User's Guide
  24. ^ [5] Archived 2014-02-09 at the Wayback Machine from the Perforce User's Guide
  25. ^ "Perforce Public Knowledge Base – Home". Perforce.com. Archived from the original on 2007-08-14. Retrieved 2014-01-26.
  26. ^ "Perforce Knowledge Base: Internationalization and Localization". Kb.perforce.com. 2010-10-21. Archived from the original on 2012-02-08. Retrieved 2014-01-26.
  27. ^ "Perforce Knowledge Base: Internationalization and Localization". Kb.perforce.com. 2010-10-21. Archived from the original on 2013-01-30. Retrieved 2014-01-26.
  28. ^ [6] – Seapine Software Releases Surround SCM 2009
  29. ^ "GitCentric | AccuRevGit for the Enterprise". Accurev.com. Archived from the original on 2012-10-17. Retrieved 2014-01-26.
  30. ^ "Bazaar keywords plugin". Wiki.bazaar.canonical.com. 2005-09-05. Archived from the original on 2014-02-01. Retrieved 2014-01-26.
  31. ^ "Bazaar interactive plugin". Launchpad.net. 7 March 2008. Retrieved 2014-01-26.
  32. ^ "Bazaar Externals plugin". Launchpad.net. 9 November 2009. Retrieved 2014-01-26.
  33. ^ "Ignore merge operation for given extension". 4 March 2010.
  34. ^ "bzr-svn". Launchpad.net. 8 May 2006. Retrieved 2014-01-26.
  35. ^ "bzr-git". Launchpad.net. 15 July 2006. Retrieved 2014-01-26.
  36. ^ "bzr-hg". Launchpad.net. 13 June 2006. Retrieved 2014-01-26.
  37. ^ IBM Rational ClearCase: The ten best triggers from IBM DeveloperWorks
  38. ^ The manifest, Fossil file formats
  39. ^ "Fossil import and export". Fossil-scm.org. 2014-01-22. Archived from the original on 2014-02-02. Retrieved 2014-01-26.
  40. ^ "FossilHelp: import"
  41. ^ "git-submodule(1) Manual Page". Kernel.org. 2013-02-15. Retrieved 2014-01-26.
  42. ^ "git-read-tree(1) Manual Page". kernel.org. 2014-08-24. Retrieved 2014-10-24.
  43. ^ "Mercurial KeywordExtension page". Mercurial-scm.org. Retrieved 2014-01-26.
  44. ^ "Mercurial RecordExtension page". Mercurial-scm.org. 2013-08-27. Retrieved 2014-01-26.
  45. ^ "Subrepository – Mercurial". Mercurial-scm.org. Retrieved 2016-04-22.
  46. ^ With the sparse extension included in core since Hg Rev.:4.3.
  47. ^ "Mercurial Timestamp Extension". Mercurial-scm.org. 2012-04-24. Retrieved 2014-01-26.
  48. ^ "Merge Tool Configuration". Mercurial-scm.org. 2017-03-14. Retrieved 2017-09-05.
  49. ^ "hgsubversion page". Mercurial-scm.org. 2013-08-28. Retrieved 2014-01-26.
  50. ^ "Hg-Git Mercurial Plugin". Hg-git.github.com. Retrieved 2014-01-26.
  51. ^ "Mercurial ConvertExtension page". Mercurial-scm.org. 2013-11-29. Retrieved 2014-01-26.
  52. ^ "Mercurial: the definitive guide: Appendix: Migrating to Mercurial"
  53. ^ a b c "P4 User's Guide". Perforce. Retrieved 19 January 2018.
  54. ^ "Keyword Substitution". Svnbook.red-bean.com. Retrieved 2014-01-26.
  55. ^ "Externals Definitions". Svnbook.red-bean.com. Retrieved 2014-01-26.
  56. ^ a b darcs's default pull command is interactive, allowing the user to choose which patches to apply (merge) in realtime
  57. ^ "Mercurial Rebase Extension". Mercurial-scm.org. 2012-10-25. Retrieved 2014-04-23.
  58. ^ "bug 6463 – enh: search repository". Retrieved 8 May 2012.
  59. ^ "Mercurial Shelve extension page". Mercurial-scm.org. 2013-11-07. Retrieved 2014-01-26.
  60. ^ "Mercurial Strip extension page". Mercurial-scm.org. Retrieved 11 May 2016.
  61. ^ "graft -core command (since Hg Rev.2.0)". Selenic.com. Retrieved 2014-01-26.
  62. ^ "Mercurial Transplant extension page". Mercurial-scm.org. 2012-05-12. Retrieved 2014-01-26.
  63. ^ "The Perforce Broker". Perforce.com. Archived from the original on 2013-11-16. Retrieved 2014-01-26.
  64. ^ "Perforce Knowledge Base: "Cherry Picking" Integrations". Kb.perforce.com. 1990-01-01. Archived from the original on 2012-03-09. Retrieved 2014-01-26.
  65. ^ "Supported Integrations – PTC Integrity". Mks.com. 2012-09-10. Archived from the original on 2012-07-25. Retrieved 2014-01-26.
  66. ^ "La Chose : web agency and software maker – agence web et développement de logiciels". Archived from the original on 2016-06-18. Retrieved 2006-09-20.
  67. ^ Distributed Source Control System. Portal.acm.org. 1997-05-18. pp. 98–107. ISBN 9783540630142. Retrieved 2014-01-26.
  68. ^ a b Towards A Better SCM: Revlogs and Mercurial, presented by Matt Mackall to the Ottawa Linux Symposium, July 2006
  69. ^ "GCC: Anonymous read-only Git access". Retrieved 24 October 2023.
  70. ^ "A Hacker's Guide to GnuPG". 11 March 2021. Retrieved 24 October 2023.
  71. ^ "Getting and Working With the Perl Source". dev.perl.org. Retrieved 2014-01-26.
  72. ^ "Setup and building". Python.org. Retrieved 2023-10-24.
  73. ^ "Git". MediaWiki. Retrieved 1 August 2012.
  74. ^ "The largest Git repo on the planet". May 24, 2017.
  75. ^ "PTC Sets New Standard for Managing Hardware and Software Development Lifecycles with MKS Integrity Acquisition – PTC Integrity". Mks.com. Archived from the original on 2014-07-22. Retrieved 2014-01-26.
  76. ^ Rochkind, Marc J. (December 1975), "The Source Code Control System" (PDF), IEEE Transactions on Software Engineering, vol. SE-1, no. 4, pp. 364–370, doi:10.1109/tse.1975.6312866, S2CID 10006076, archived from the original (PDF) on 2011-05-25, retrieved 2014-07-31
  77. ^ http://minnie.tuhs.org/cgi-bin/utree.pl?file=PWB1/usr/news/pibs PWB UNIX product announcement
  78. ^ Compare the SCCS 4 file format with the SCCS 5.0 Archived 2014-08-19 at the Wayback Machine file format (as manpage sccsfile(4) in "Archived copy". Archived from the original on 2014-08-19. Retrieved 2014-08-17.{{cite web}}: CS1 maint: archived copy as title (link)
  79. ^ Starteam®


Retrieved from "https://en.wikipedia.org/w/index.php?title=Comparison_of_version-control_software&oldid=1244434443"