version control - usados - Comparación entre sistemas de control de versiones centralizadas y distribuidas
sistemas de control de versiones mas usados (15)
¿Cuáles son los beneficios y desventajas con el uso de Sistemas de Control de Versión Centralizados versus Distribuidos (DVCS)? ¿Ha tenido algún problema con DVCS y cómo se ha salvaguardado de estos problemas? Mantenga la herramienta de discusión agnóstica y llameante al mínimo.
Para aquellos que se preguntan qué herramientas de 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 Linux Kernel 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).
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 kernel 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 hacían cosas diferentes, pero recientemente decidieron que todo lo que un repositorio centralizado puede hacer, distribuido, puede hacerlo mejor.
Por ejemplo, supongamos que eres un desarrollador en solitario que trabaja en tu propio proyecto personal. Un repositorio centralizado podría ser una opción obvia, pero considere este escenario. Estás lejos del acceso a la red (en un avión, en un parque, etc.) y quieres trabajar en tu proyecto. Tiene su copia local para que pueda trabajar bien pero realmente desea comprometerse porque ha terminado una característica y desea pasar a otra, o ha encontrado un error para arreglar o lo que sea. El punto es que con un repositorio centralizado termina machacando todos los cambios juntos y comprometiéndolos en un conjunto de cambios no lógico o los divide manualmente más tarde.
Con un repositorio distribuido puede continuar como siempre, comprometerse, seguir adelante, cuando tenga acceso a la red nuevamente, presione hacia su "único repositorio verdadero" y nada cambiará.
Por no mencionar la otra cosa agradable acerca de los repos distribuidos: historia completa disponible siempre. ¿Necesita ver los registros de revisión cuando está fuera de la red? ¿Necesita anotar la fuente para ver cómo se introdujo un error? Todo es posible con repos distribuidos.
Por favor, no crean que distribuido vs centralizado es sobre propiedad o copias autorizadas o algo por el estilo. La realidad que se distribuye es el siguiente paso en la evolución de SCM.
De mi respuesta a una question diferente:
Los sistemas de control de versiones distribuidas (DVCS) resuelven diferentes problemas que los VCS centralizados. Compararlos es como comparar martillos y destornilladores.
Los sistemas centralizados de VCS están diseñados con la intención de que haya una sola fuente verdadera bendecida y, por lo tanto, buena. Todos los desarrolladores trabajan (checkout) desde esa fuente, y luego agregan (confirman) sus cambios, que luego se bendicen de manera similar. La única diferencia real entre CVS, Subversion, ClearCase, Perforce, VisualSourceSafe y todos los demás CVCS está en el flujo de trabajo, el rendimiento y la integración que ofrece cada producto.
Los sistemas distribuidos de VCS 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é depósito se debe confiar se impone desde el exterior por el proceso, no por el software en sí.
La elección real entre el uso de un tipo u otro es organizacional: si su proyecto u organización desea un control centralizado, entonces un DVCS no es un iniciador. 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 es probablemente su salvación. Si necesitas ambas, estás fsck''d.
Durante mi búsqueda del SCM correcto, encontré los siguientes enlaces de gran ayuda:
- Mejor Iniciativa SCM: Comparación . Comparación de aproximadamente 26 sistemas de control de versiones.
- Comparación del software de control de revisiones . Artículo de Wikipedia que compara aproximadamente 38 sistemas de control de versiones que cubren temas como diferencias técnicas, características, interfaces de usuario y más.
- Sistemas de control de versiones distribuidas . Otra comparación, pero se centró principalmente en sistemas distribuidos.
El problema principal (aparte del problema obvio del ancho de banda) es la propiedad .
Eso es para estar seguro de que el sitio diferente (geográfico) no está trabajando en el mismo elemento que el otro.
Idealmente, la herramienta puede asignar 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 posee qué, y luego se comunique (a través del teléfono, IM o correo) con el sitio distante.
Si no tiene el mecanismo de propiedad ... se "comunicará", pero a menudo demasiado tarde;) (es decir, después de haber hecho un desarrollo concurrente en un conjunto idéntico de archivos en la misma rama. El compromiso puede volverse desordenado)
Hasta cierto punto, los dos esquemas son equivalentes:
- Un VCS distribuido puede emular trivialmente uno centralizado si siempre empuja sus cambios a algún repositorio en sentido ascendente designado después de cada confirmación local.
- Por lo general, un VCS centralizado no podrá emular a uno distribuido de forma tan natural, pero puede obtener algo muy similar si usa algo parecido a una quilt encima. Quilt, si no está familiarizado con él, es una herramienta para administrar grandes conjuntos de parches sobre algún proyecto en sentido ascendente. La idea aquí es que el comando de confirmación DVCS se implemente mediante la creación de un nuevo parche, y el comando push se implementa al comprometer cada parche sobresaliente al VCS centralizado y luego descartar los archivos de parche. Esto suena un poco incómodo, pero en la práctica, en realidad funciona bastante bien.
Una vez dicho esto, hay un par de cosas que los DVCS tradicionalmente hacen muy bien y de los cuales los VCS más centralizados son un poco exagerados. Probablemente, el más importante de estos sea el de la bifurcación: un DVCS facilitará la bifurcación del repositorio o la fusión de sucursales que ya no son necesarias, y hará un seguimiento del historial mientras lo hace. No hay una razón particular por la cual un esquema centralizado tenga problemas con esto, pero históricamente nadie parece haberlo logrado todavía. Si eso es realmente un problema para usted depende de cómo va a organizar el desarrollo, pero para muchas personas es una consideración importante.
La otra ventaja de DVCSes es que trabajan fuera de línea. Nunca he tenido mucho uso para eso; Principalmente desarrollo en la oficina (por lo que el repositorio está en la red local) o en casa (por lo que hay ADSL). Si hace un gran desarrollo en las computadoras portátiles mientras viaja, esto podría ser más una consideración para usted.
En realidad, no hay muchos errores específicos de DVCS. Hay una tendencia levemente mayor a que las personas se callen, porque puedes comprometerte sin presionar y es fácil terminar 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 por lo general están familiarizados con el modelo de desarrollo de parche comercial, pero los desarrolladores entrantes de código cerrado también parecen recoger las cosas de manera razonablemente rápida.
He estado usando la subversión durante muchos años y estaba muy contento con ella.
Entonces comenzó el zumbido de GIT y solo tuve que probarlo. Y para mí, el principal argumento de venta fue la ramificación. Oh chico. Ahora ya no necesito limpiar mi repositorio, retroceder algunas versiones o cualquiera de las cosas tontas que hice cuando uso subversion. Todo es barato en dvcs. Sin embargo, solo he probado fósiles y git, pero he usado forzadamente, cvs y subversión y parece que todos los dvcs tienen ramificaciones y etiquetados realmente baratos. Ya no es necesario copiar todo el código en un lado y, por lo tanto, la fusión es simplemente una brisa.
Cualquier dvcs se puede configurar con un servidor central, pero lo que obtienes es, entre otras cosas
Puedes registrar cualquier cambio pequeño que desees, ya que Linus dice que si necesitas usar más de una oración para describir lo que acabas de hacer, estás haciendo demasiado. Puede hacer su trabajo con el código, la bifurcación, la fusión, la clonación y la prueba local sin que nadie descargue gran cantidad de datos. Y solo necesita insertar los cambios finales en el servidor central.
Y puedes 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 finalizar la compra de Git: git
Para finalizar la compra de Fossil: fossil-scm.org
Para pagar Mercurial: https://www.mercurial-scm.org
Ahora, solo puedo recomendar sistemas dvcs, y usted puede usar fácilmente un servidor central
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 la subversión 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 de administración, pero esa es otra historia). En todo caso. realmente se trata de equilibrar qué conjuntos de características te hacen más productivo con lo que la organización necesita (autenticación centralizada, por ejemplo).
No es realmente una comparación, pero aquí están los grandes proyectos que están usando:
VCS centralizados
Apache, GCC, Ruby, MPlayer, Zope, Plone, Xiph, FreeBSD, WebKit, ...
CVS
CVS
VCS distribuidos
Kernel de Linux, KDE, Perl, Ruby on Rails, Android, Wine, Fedora, X.org, Mediawiki, Django, VLC, Mono, Gnome, Samba, CUPS, GnuPG, Emacs ELPA ...
Mozilla y Mozdev, OpenJDK (Java), OpenSolaris, ALSA, NTFS-3G, Dovecot, MoinMoin, mutt, PETSc, Octave, FEniCS, Aptitude, Python, XEmacs, Xen, Vim, Xine ...
Emacs, Apt, Mailman, MySQL, Squid, ... también promocionado dentro de Ubuntu.
ghc, ion, xmonad, ... popular dentro de la comunidad Haskell.
SQLite
Otra ventaja para SCM distribuido incluso en el caso de un desarrollador individual es si usted, como muchos de nosotros, tiene más de una máquina en la que trabaja.
Digamos que tienes un conjunto de scripts comunes. Si cada máquina en la que trabaja tiene un clon, puede bajo demanda actualizar y cambiar sus scripts. Te lo dá:
- un ahorro de tiempo, especialmente con las teclas ssh
- una forma de ramificar las diferencias entre diferentes sistemas (por ejemplo, Red Hat vs Debian, BSD vs Linux, etc.)
Para mí, esta es otra discusión sobre un gusto personal y es bastante difícil ser realmente objetivo. Yo personalmente prefiero Mercurial sobre el otro DVCS. Me gusta escribir anzuelos en el mismo idioma en el que está escrito Mercurial y la sobrecarga de red más pequeña, solo para decir algunos de mis motivos.
Tengo la sensación de que Mercurial (y otros DVCS) son más sofisticados que los centralizados. Por ejemplo, la fusión de una sucursal en Mercurial conserva el historial completo de la sucursal, mientras que en SVN debe ir al directorio de sucursal para ver el historial.
Todos estos días están en el carro de cómo los DVCS son superiores, pero el comentario de Craig es importante. En un DVCS, cada persona tiene el historial completo 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 diffs.
Un sistema centralizado no necesariamente le impide usar ramas separadas para desarrollar. No es necesario que haya una sola copia verdadera de la base de código, en lugar de diferentes desarrolladores o equipos pueden tener diferentes ramas, pueden existir ramas heredadas, etc.
Lo que generalmente significa es que el repositorio se administra de forma 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.
W. Craig Trader dijo esto sobre DVCS y CVCS:
Si necesitas ambas, estás fsck''d.
No diría que estás fsckd cuando usas ambos. Prácticamente los desarrolladores que usan herramientas DVCS generalmente intentan fusionar sus cambios (o enviar solicitudes de extracción) a una ubicación central (generalmente a una rama de publicación en un repositorio de versiones). Existe cierta ironía con los desarrolladores que usan DVCS pero que al final se atienen a un flujo de trabajo centralizado, puede comenzar a preguntarse si el enfoque distribuido realmente es mejor que el centralizado.
Hay algunas ventajas con DVCS en un CVCS:
La noción de compromisos únicos y reconocibles hace que el envío de parches entre pares sea sencillo. Es decir, haces que el parche sea un compromiso, y lo compartes con otros desarrolladores que lo necesiten. Más tarde, cuando todos deseen fusionarse, ese compromiso en particular se reconoce y se puede comparar entre las ramas, teniendo menos posibilidades de fusionarse. Los desarrolladores tienden a enviarse parches entre ellos mediante dispositivo 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 aumenta las posibilidades de que se produzca un conflicto.
Puede tener ramas experimentales locales (los repositorios clonados también pueden considerarse una rama) que no necesita mostrar a otros. Eso significa que no es necesario que los cambios de última hora afecten a los desarrolladores si no has impulsado nada en sentido ascendente. En un CVCS, cuando todavía tenga un cambio de rotura, es posible que deba trabajar fuera de línea hasta que lo haya arreglado y haya confirmado los cambios para entonces. Este enfoque efectivamente frustra el propósito de usar el control de versiones como una red de seguridad, pero es un mal necesario en CVCS.
En el mundo de hoy, las compañías generalmente trabajan con desarrolladores off-shore (o si es aún 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 cada uno tiene su propio repositorio.
... y algunas desventajas que generalmente tienen soluciones temporales:
¿Quién tiene la última revisión? En un CVCS, el tronco generalmente tiene la última revisión, pero en un DVCS puede no ser claramente obvio. La solución consiste en utilizar reglas de conducta para que los desarrolladores de un proyecto lleguen a un acuerdo en el que repo fusionar su trabajo.
Los bloqueos pesimistas, es decir, un archivo está bloqueado al hacer un check-out, generalmente no son posibles debido a la concurrencia que puede ocurrir entre los depósitos en DVCS. La razón por la cual el bloqueo de archivos existe en el control de versiones se debe a que los desarrolladores desean evitar los conflictos de combinación. Sin embargo, el bloqueo tiene la desventaja de desacelerar el desarrollo ya que dos desarrolladores no pueden trabajar en la misma pieza de código simultáneamente que con un modelo de transacción largo y no es una garantía de prueba completa contra los conflictos de fusión. La única manera sensata, independientemente del control de versión, es combatir grandes conflictos de fusión es tener una buena arquitectura de código (cohesión baja de alta cohesión) y dividir sus tareas de trabajo para que tengan un bajo impacto en el código (lo cual es más fácil decirlo que hacerlo) .
En proyectos de propiedad privada sería desastroso si todo el repositorio estuviera disponible públicamente. Aún más si un programador descontento o malicioso se apodera de un repositorio clonado. La fuga de código fuente es un dolor severo para las empresas propietarias. DVCS lo simplifica, 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 compañía, entonces ningún control de versiones en el mundo lo ayudará a evitar la fuga de código fuente.
Los VCS distribuidos son atractivos de muchas maneras, pero una desventaja que será importante para mi empresa es la gestión de archivos que no se pueden combinar (normalmente binarios, por ejemplo, documentos de Excel). Subversion se encarga de esto al admitir la propiedad "svn: needs-lock", lo que significa que debe obtener un candado para el archivo que no es mergable antes de editarlo. Funciona bien. Pero ese flujo de trabajo requiere un modelo de repositorio centralizado, que es contrario al concepto de DVCS.
Por lo tanto, si desea utilizar un DVCS, no es realmente apropiado para administrar archivos que no se pueden combinar.