Comparación entre sistemas de control de versiones centralizados y distribuidos [cerrado]

¿Cuáles son los beneficios y los inconvenientes de utilizar sistemas de control de versiones centralizados frente a distribuidos (DVCS)? ¿Ha tenido algún problema en DVCS y cómo se protegió contra estos problemas? Mantenga la herramienta de discusión agnóstica y llamativa al mínimo.

Para aquellos que se preguntan qué herramientas DVCS están disponibles, aquí hay una lista de los DVCS gratuitos / de código abierto más conocidos:

• Git (escrito en C) utilizado por el Kernel de Linux y Ruby on Rails .
• Mercurial , (escrito en Python) utilizado por Mozilla y OpenJDK .
• Bazaar , (escrito en Python) utilizado por los desarrolladores de Ubuntu .
• Darcs , (escrito en Haskell).

De mi respuesta a una pregunta diferente :

Los sistemas de control de versiones distribuidos (DVCS) resuelven diferentes problemas que los VCS centralizados. Compararlos es como comparar martillos y destornilladores.

Los sistemas de VCS centralizados están diseñados con la intención de que haya Una Fuente Verdadera que sea Bendita y, por lo tanto, Buena. Todos los desarrolladores trabajan (pago) desde esa fuente y luego agregan (confirman) sus cambios, que luego se vuelven igualmente bendecidos. La única diferencia real entre CVS, Subversion, ClearCase, Perforce, VisualSourceSafe y todos los demás CVCSes está en el flujo de trabajo, el rendimiento y la integración que ofrece cada producto.

Los sistemas VCS distribuidos están diseñados con la intención de que un repositorio sea tan bueno como cualquier otro, y que las fusiones de un repositorio a otro sean solo otra forma de comunicación. Cualquier valor semántico en cuanto a qué repositorio debe ser confiable es impuesto desde el exterior por el proceso, no por el software en sí.

La verdadera elección entre usar un tipo u otro es organizacional: si su proyecto u organización desea un control centralizado, entonces un DVCS no es un principiante. Si se espera que sus desarrolladores trabajen en todo el país / mundo, sin conexiones seguras de banda ancha a un repositorio central, entonces DVCS probablemente sea su salvación. Si necesita ambos, está jodido.

Para aquellos que piensan que los sistemas distribuidos no permiten copias autorizadas, tenga en cuenta que hay muchos lugares donde los sistemas distribuidos tienen copias autorizadas, el ejemplo perfecto es probablemente el árbol del núcleo de Linus. Seguro que mucha gente tiene sus propios árboles, pero casi todos fluyen hacia el árbol de Linus.

Dicho esto, solía pensar que los SCM distribuidos solo eran útiles para muchos desarrolladores que hacen cosas diferentes, pero recientemente he decidido que cualquier cosa que un repositorio centralizado pueda hacer que uno distribuido puede hacerlo mejor.

Por ejemplo, supongamos que es un desarrollador en solitario que trabaja en su propio proyecto personal. Un repositorio centralizado podría ser una opción obvia, pero considere este escenario. Está lejos del acceso a la red (en un avión, en un parque, etc.) y desea trabajar en su proyecto. Tiene su copia local para que pueda trabajar bien, pero realmente quiere comprometerse porque ha terminado una función y desea pasar a otra, o encontró un error para corregir o lo que sea. El punto es que con un repositorio centralizado terminas combinando todos los cambios y comprometiéndolos en un conjunto de cambios no lógico o los divides manualmente más tarde.

Con un repositorio distribuido, usted sigue con sus negocios como de costumbre, se compromete, sigue adelante, cuando tiene acceso a la red de nuevo, ingresa a su "único repositorio verdadero" y nada cambia.

Sin mencionar la otra cosa buena de los repositorios distribuidos: el historial completo siempre está disponible. ¿Necesita mirar los registros de revisión cuando está lejos de la red? ¿Necesita anotar la fuente para ver cómo se introdujo un error? Todo es posible con repositorios distribuidos.

Por favor, no crea que distribuido vs centralizado se trata de propiedad o copias autorizadas o algo por el estilo. La realidad se distribuye es el siguiente paso en la evolución de SCM.

No es realmente una comparación, pero esto es lo que están usando los grandes proyectos:

VCSes centralizados

• Subversión

  Apache, GCC, Ruby, MPlayer, Zope, Plone, Xiph, FreeBSD, WebKit, ...

• CVS

  CVS

VCSes distribuidos

• git

  Kernel de Linux, KDE, Perl, Ruby on Rails, Android, Wine, Fedora, X.org, Mediawiki, Django, VLC, Mono, Gnome, Samba, CUPS, GnuPG, Emacs ELPA ...

• mercurial (hg)

  Mozilla y Mozdev, OpenJDK (Java), OpenSolaris, ALSA, NTFS-3G, Dovecot, MoinMoin, mutt, PETSc, Octave, FEniCS, Aptitude, Python, XEmacs, Xen, Vim, Xine ...

• bzr

  Emacs, Apt, Mailman, MySQL, Squid, ... también promocionados dentro de Ubuntu.

• darcs

  ghc, ion, xmonad, ... popular dentro de la comunidad Haskell.

• fósil

  SQLite

W. Craig Trader dijo esto sobre DVCS y CVCS:

Si necesita ambos, está jodido.

No diría que estás sorprendido cuando usas ambos. Prácticamente, los desarrolladores que usan herramientas DVCS generalmente intentan fusionar sus cambios (o enviar solicitudes de extracción) en una ubicación central (generalmente a una rama de lanzamiento en un repositorio de lanzamiento). Hay algo de ironía con los desarrolladores que usan DVCS, pero al final se adhieren a un flujo de trabajo centralizado, puede comenzar a preguntarse si el enfoque distribuido es realmente mejor que el centralizado.

Hay algunas ventajas con DVCS sobre CVCS:

• La noción de confirmaciones reconocibles de forma única hace que el envío de parches entre pares sea indoloro. Es decir, crea el parche como un compromiso y lo comparte con otros desarrolladores que lo necesiten. Más tarde, cuando todos quieran fusionarse, se reconoce esa confirmación en particular y se puede comparar entre ramas, lo que tiene menos posibilidades de conflicto de fusión. Los desarrolladores tienden a enviarse parches entre sí mediante una memoria USB o correo electrónico, independientemente de la herramienta de control de versiones que utilice. Desafortunadamente, en el caso de CVCS, el control de versiones registrará las confirmaciones como separadas, sin reconocer que los cambios son los mismos, lo que aumentará la posibilidad de un conflicto de fusión.

• Puede tener ramas experimentales locales (los repositorios clonados también se pueden considerar una rama) que no necesita mostrar a otros. Eso significa que los cambios rotundos no tienen por qué afectar a los desarrolladores si no ha impulsado nada hacia arriba. En un CVCS, cuando todavía tiene un cambio importante, es posible que deba trabajar sin conexión hasta que lo haya solucionado y haya confirmado los cambios para entonces. Este enfoque anula efectivamente el propósito de usar el control de versiones como red de seguridad, pero es un mal necesario en CVCS.

• En el mundo actual, las empresas suelen trabajar con desarrolladores externos (o, si es mejor, quieren trabajar desde casa). Tener un DVCS ayuda a este tipo de proyectos porque elimina la necesidad de una conexión de red confiable ya que todos tienen su propio repositorio.

… Y algunas desventajas que suelen tener soluciones:

• ¿Quién tiene la última revisión? En un CVCS, el tronco generalmente tiene la última revisión, pero en un DVCS puede que no sea claramente obvio. La solución es usar reglas de conducta, que los desarrolladores de un proyecto deben llegar a un acuerdo en el que el repositorio fusionará su trabajo.

• Los bloqueos pesimistas, es decir, un archivo está bloqueado cuando se realiza una extracción, generalmente no son posibles debido a la concurrencia que puede ocurrir entre los repositorios en DVCS. La razón por la que existe el bloqueo de archivos en el control de versiones es porque los desarrolladores quieren evitar conflictos de fusión. Sin embargo, el bloqueo tiene la desventaja de ralentizar el desarrollo ya que dos desarrolladores no pueden trabajar en la misma pieza de código simultáneamente como con un modelo de transacción larga y no es una garantía de prueba completa contra conflictos de fusión. La única forma sensata, independientemente del control de versiones, es combatir los grandes conflictos de fusión es tener una buena arquitectura de código (como un bajo acoplamiento y alta cohesión) y dividir sus tareas de trabajo para que tengan un bajo impacto en el código (que es más fácil decirlo que hacerlo) .

• En los proyectos propietarios, sería desastroso si todo el repositorio estuviera disponible públicamente. Más aún si un programador descontento o malintencionado se apodera de un repositorio clonado. La fuga de código fuente es un problema severo para las empresas propietarias. DVCS hace que esto sea simple, ya que solo necesita clonar el repositorio, mientras que algunos sistemas CM (como ClearCase) intentan restringir ese acceso. Sin embargo, en mi opinión, si tiene una cantidad suficiente de disfuncionalidad en la cultura de su empresa, entonces ningún control de versiones en el mundo lo ayudará contra la filtración del código fuente.

Durante mi búsqueda del SCM adecuado, encontré que los siguientes enlaces son de gran ayuda:

1. Mejor iniciativa SCM: comparación . Comparación de unos 26 sistemas de control de versiones.
2. Comparación de software de control de revisiones . Artículo de Wikipedia que compara alrededor de 38 sistemas de control de versiones que cubren temas como diferencias técnicas, características, interfaces de usuario y más.
3. Sistemas de control de versiones distribuidos . Otra comparación, pero centrada principalmente en sistemas distribuidos.

Hasta cierto punto, los dos esquemas son equivalentes:

• Un VCS distribuido puede emular trivialmente uno centralizado si siempre envía sus cambios a algún repositorio ascendente designado después de cada confirmación local.
• Un VCS centralizado generalmente no podrá emular uno distribuido con tanta naturalidad, pero puede obtener algo muy similar si usa algo como una colcha encima. Quilt, si no está familiarizado con él, es una herramienta para administrar grandes conjuntos de parches además de algún proyecto anterior. La idea aquí es que el comando de confirmación de DVCS se implemente mediante la creación de un nuevo parche, y el comando push se implemente al enviar cada parche pendiente al VCS centralizado y luego descartar los archivos de parche. Esto suena un poco incómodo, pero en la práctica funciona bastante bien.

Habiendo dicho eso, hay un par de cosas que los DVCS tradicionalmente hacen muy bien y que la mayoría de los VCS centralizados hacen un poco de hash. El más importante de ellos probablemente sea la ramificación: un DVCS hará que sea muy fácil ramificar el repositorio o fusionar las ramificaciones que ya no son necesarias, y mantendrá un registro del historial mientras lo hace. No hay ninguna razón en particular por la que un esquema centralizado tenga problemas con esto, pero históricamente nadie parece haberlo hecho bien todavía. Si eso es realmente un problema para usted depende de cómo vaya a organizar el desarrollo, pero para muchas personas es una consideración importante.

La otra ventaja propuesta de los DVCS es que funcionan sin conexión. Realmente nunca he tenido mucho uso para eso; Principalmente hago desarrollo en la oficina (por lo que el repositorio está en la red local) o en casa (por lo que hay ADSL). Si desarrolla mucho en computadoras portátiles mientras viaja, entonces esto podría ser más una consideración para usted.

En realidad, no hay muchas trampas que sean específicas de los DVCS. Hay una tendencia un poco mayor a que la gente se quede callada, porque te puedes comprometer sin empujar y es fácil acabar puliendo cosas en privado, pero aparte de eso no hemos tenido muchos problemas. Esto puede deberse a que tenemos un número significativo de desarrolladores de código abierto, que generalmente están familiarizados con el modelo de desarrollo de intercambio de parches, pero los desarrolladores de código cerrado entrantes también parecen recoger las cosas razonablemente rápido.

He estado usando Subversion durante muchos años y estaba muy contento con él.

Entonces comenzó el zumbido de GIT y tuve que probarlo. Y para mí, el principal punto de venta fue la ramificación. Oh chico. Ahora ya no necesito limpiar mi repositorio, retroceder algunas versiones o cualquiera de las tonterías que hice al usar subversion. Todo es barato en dvcs. Sin embargo, solo he probado fossil y git, pero he usado force, cvs y subversion y parece que todos los dvcs tienen ramificaciones y etiquetado realmente baratos. Ya no es necesario copiar todo el código a un lado y, por lo tanto, la combinación es muy sencilla.

Cualquier DVC puede configurarse con un servidor central, pero lo que obtiene es, entre otras cosas

Puede marcar cualquier pequeño cambio que desee, como dice Linus, si necesita usar más de una oración para describir lo que acaba de hacer, está haciendo demasiado. Puede salirse con la suya con el código, bifurcar, fusionar, clonar y probar todo localmente sin que nadie descargue una gran cantidad de datos. Y solo necesita enviar los cambios finales al servidor central.

Y puede trabajar sin red.

En resumen, usar un control de versiones siempre es algo bueno. Usar dvcs es más barato (en KB y ancho de banda), y creo que es más divertido de usar.

Para verificar Git: http://git-scm.com/
Para verificar Fossil: http://www.fossil-scm.org
Para verificar Mercurial: https://www.mercurial-scm.org

Ahora, solo puedo recomendar sistemas dvcs, y puedes usar fácilmente un servidor central

Los VCS distribuidos son atractivos en muchos sentidos, pero una desventaja que será importante para mi empresa es la cuestión de la gestión de archivos que no se pueden fusionar (normalmente binarios, por ejemplo, documentos de Excel). Subversion se ocupa de esto al admitir la propiedad "svn: needs-lock", lo que significa que debe obtener un bloqueo para el archivo no fusionable antes de editarlo. Funciona bien. Pero ese flujo de trabajo requiere un modelo de repositorio centralizado, que es contrario al concepto DVCS.

Entonces, si desea usar un DVCS, no es realmente apropiado para administrar archivos que no se pueden fusionar.

El principal problema (aparte del problema obvio del ancho de banda) es la propiedad .

Eso es para asegurarse de que un sitio (geográfico) diferente no esté trabajando en el mismo elemento que el otro.

Idealmente, la herramienta puede asignar la propiedad a un archivo, una rama o incluso un repositorio.

Para responder a los comentarios de esta respuesta, realmente desea que la herramienta le diga quién es el propietario de qué y luego se comunique (por teléfono, mensajería instantánea o correo) con el sitio distante.
Si no tiene un mecanismo de propiedad ... se "comunicará", pero a menudo es demasiado tarde;) (es decir, después de haber realizado un desarrollo simultáneo en un conjunto idéntico de archivos en la misma rama. La confirmación puede complicarse)

Para mí, esta es otra discusión sobre un gusto personal y es bastante difícil ser realmente objetivo. Personalmente prefiero Mercurial sobre los otros DVCS. Me gusta escribir ganchos en el mismo idioma en el que está escrito Mercurial y la sobrecarga de red más pequeña, solo por decir algunas de mis propias razones.

Todos en estos días están en el tren de cómo los DVCS son superiores, pero el comentario de Craig es importante. En un DVCS, cada persona tiene la historia completa de la sucursal. Si está trabajando con muchos archivos binarios (por ejemplo, archivos de imagen o FLA), esto requiere una gran cantidad de espacio y no puede hacer diferencias.

Tengo la sensación de que Mercurial (y otros DVCS) son más sofisticados que los centralizados. Por ejemplo, fusionar una rama en Mercurial mantiene el historial completo de la rama mientras que en SVN tienes que ir al directorio de la rama para ver el historial.

Otra ventaja de SCM distribuido, incluso en el escenario de un desarrollador individual, es si usted, como muchos de nosotros, tiene más de una máquina en la que trabaja.

Digamos que tiene un conjunto de scripts comunes. Si cada máquina en la que trabaja tiene un clon, puede actualizar y cambiar sus scripts bajo demanda. Te lo dá:

1. un ahorro de tiempo, especialmente con teclas ssh
2. una forma de ramificar diferencias entre diferentes sistemas (por ejemplo, Red Hat vs Debian, BSD vs Linux, etc.)

La respuesta de W. Craig Trader resume la mayor parte, sin embargo, creo que el estilo de trabajo personal también marca una gran diferencia. Donde trabajo actualmente usamos subversion como nuestra única fuente verdadera, sin embargo, muchos desarrolladores usan git-svn en sus máquinas personales para compensar el problema del flujo de trabajo que tenemos (falla en la administración, pero esa es otra historia). En todo caso. en realidad, se trata de equilibrar qué conjuntos de funciones lo hacen más productivo con lo que necesita la organización (autenticación centralizada, por ejemplo).

Un sistema centralizado no necesariamente le impide usar ramas separadas para desarrollar. No es necesario que haya una única copia verdadera del código base, sino que diferentes desarrolladores o equipos pueden tener diferentes ramas, podrían existir ramas heredadas, etc.

Lo que generalmente significa es que el repositorio se administra de manera centralizada, pero eso generalmente es una ventaja en una empresa con un departamento de TI competente porque significa que solo hay un lugar para realizar copias de seguridad y solo un lugar para administrar el almacenamiento.