¿Cuáles son las fortalezas y debilidades relativas de Git, Mercurial y Bazaar?[cerrado]
https://stackoverflow.com/questions/77485
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
¿Cuáles ven la gente aquí como las fortalezas y debilidades relativas de Git, Mercurial y Bazaar?
Al considerar cada uno de ellos entre sí y con sistemas de control de versiones como SVN y Perforce, ¿qué cuestiones se deben considerar?
Al planificar una migración de SVN a uno de estos sistemas de control de versiones distribuidos, ¿qué factores consideraría?
Solución
Git es muy rápido, escala muy bien y es muy transparente acerca de sus conceptos.La desventaja de esto es que tiene una curva de aprendizaje relativamente pronunciada.Hay disponible un puerto Win32, pero no es del todo un ciudadano de primera clase.Git expone hashes como números de versión a los usuarios;esto proporciona garantías (en el sentido de que un único hash siempre se refiere exactamente al mismo contenido;un atacante no puede modificar el historial sin ser detectado), pero puede resultar engorroso para el usuario.Git tiene un concepto único de seguimiento del contenido de los archivos, incluso cuando esos contenidos se mueven entre archivos y ve los archivos como objetos de primer nivel, pero no realiza un seguimiento de los directorios.Otro problema con git es que tiene muchas operaciones (como rebase) que facilitan la modificación del historial (en cierto sentido, el contenido al que hace referencia un hash nunca cambiará, pero las referencias a ese hash pueden perderse);A algunos puristas (incluido yo mismo) eso no les gusta mucho.
Bazaar es razonablemente rápido (muy rápido para árboles con un historial superficial, pero actualmente escala mal con la longitud del historial) y es fácil de aprender para aquellos familiarizados con las interfaces de línea de comandos de los SCM tradicionales (CVS, SVN, etc.).Win32 es considerado un objetivo de primera clase por su equipo de desarrollo.Tiene una arquitectura conectable para diferentes componentes y reemplaza su formato de almacenamiento con frecuencia;esto les permite introducir nuevas características (como un mejor soporte para la integración con sistemas de control de revisiones basados en diferentes conceptos) y mejorar el rendimiento.El equipo de Bazaar considera que el soporte de seguimiento de directorios y cambio de nombre es una funcionalidad de primera clase.Si bien hay identificadores de ID de revisión únicos a nivel mundial disponibles para todas las revisiones, los revnos locales de árbol (números de revisión estándar, más parecidos a los utilizados por svn u otros SCM más convencionales) se utilizan en lugar de hashes de contenido para identificar revisiones.Bazaar admite "pagos ligeros", en los que el historial se guarda en un servidor remoto en lugar de copiarse al sistema local y se consulta automáticamente a través de la red cuando es necesario;en la actualidad, esto es único entre los DSCM.
Ambos tienen alguna forma de integración SVN disponible;sin embargo, bzr-svn es considerablemente más capaz que git-svn, en gran parte debido a las revisiones de formato de backend introducidas para ese propósito. [Actualización, a partir de 2014:El producto comercial de terceros SubGit proporciona una interfaz bidireccional entre SVN y Git que es comparable en fidelidad a bzr-svn y considerablemente más pulida;I fuertemente recomiendo su uso sobre el de git-svn cuando las limitaciones de presupuesto y licencia lo permitan].
No he usado Mercurial extensamente, por lo que no puedo comentarlo en detalle, excepto para señalar que, al igual que Git, tiene direcciones de hash de contenido para revisiones;Al igual que Git, no trata los directorios como objetos de primera clase (y no puede almacenar un directorio vacío).Sin embargo, es más rápido que cualquier otro DSCM excepto Git y tiene una integración IDE mucho mejor (especialmente para Eclipse) que cualquiera de sus competidores.Dadas sus características de rendimiento (que están sólo ligeramente por detrás de las de Git) y su superior soporte multiplataforma e IDE, Mercurial puede ser atractivo para equipos con un número significativo de miembros centrados en win32 o vinculados a IDE.
Una preocupación al migrar desde SVN es que las interfaces GUI de SVN y la integración IDE son más maduras que las de cualquiera de los SCM distribuidos.Además, si actualmente hace un uso intensivo de la automatización de scripts de confirmación previa con SVN (es decir,requerir que se aprueben pruebas unitarias antes de que pueda continuar una confirmación), probablemente querrás usar una herramienta similar a PQM para automatizar solicitudes de fusión a sus sucursales compartidas.
SVK es un DSCM que utiliza Subversion como almacén de respaldo y tiene una integración bastante buena con herramientas centradas en SVN.Sin embargo, tiene características de rendimiento y escalabilidad dramáticamente peores que cualquier otro DSCM importante (incluso Darcs), y debe evitarse en proyectos que puedan crecer en términos de longitud de historial o número de archivos.
[Sobre el Autor:Utilizo Git y Perforce para trabajar, y Bazaar para mis proyectos personales y como biblioteca integrada;Otras partes de la organización de mi empleador usan mucho Mercurial.En una vida anterior construí una gran automatización en torno a SVN;antes de eso tengo experiencia con GNU Arch, BitKeeper, CVS y otros.Git fue bastante desagradable al principio: parecía GNU Arch en tanto que era un entorno con muchos conceptos, a diferencia de los kits de herramientas creados para ajustarse a los flujos de trabajo elegidos por el usuario, pero desde entonces me he sentido bastante cómodo con él].
Otros consejos
Steve Streeting del proyecto Ogre 3D acaba de publicar (28/9/2009) una entrada de blog sobre este tema en la que hace un trabajo excelente e imparcial. comparación de Git, Mercurial y Bazaar.
Al final encuentra fortalezas y debilidades con los tres y ningún ganador claro.En el lado positivo, ofrece una gran tabla para ayudarte a decidir con cuál elegir.
Es una lectura corta y la recomiendo ampliamente.
¿Cuáles ven la gente aquí como las fortalezas y debilidades relativas de Git, Mercurial y Bazaar?
En mi opinión git La fuerza es su diseño limpio subyacente y su conjunto muy rico de características.Creo que también tiene el mejor soporte para repositorios de múltiples sucursales y para administrar flujos de trabajo con muchas sucursales.Es muy rápido y tiene un tamaño de repositorio pequeño.
Tiene algunas características que son útiles pero que requieren un poco de esfuerzo para acostumbrarse a ellas.Esos incluyen visible ara de preparación intermedia (índice) entre el área de trabajo y la base de datos del repositorio, lo que permite una mejor resolución de fusión en casos más complicados, comisión incremental y comisión con árbol sucio; detector cambia el nombre y las copias usando heurística de similitud en lugar de rastrearlos usando algún tipo de identificación de archivo, lo que funciona bien y permite culpar (anotar) que puede seguir el movimiento del código entre archivos y no solo cambios de nombre al por mayor.
Una de sus desventajas es que el soporte de MS Windows se queda atrás y no es completo.Otra desventaja percibida es que no está tan bien documentado como, por ejemplo, Mercurial, y es menos fácil de usar que la competencia, pero cambia.
En mi opinión Mercurial La fortaleza radica en su buen rendimiento y tamaño de repositorio pequeño, en su buen soporte para MS Windows.
En mi opinión, la principal desventaja es el hecho de que las sucursales locales (múltiples sucursales en un solo repositorio) siguen siendo ciudadanos de segunda clase y, de una manera extraña y complicada, implementan etiquetas.Además, la forma en que maneja los cambios de nombre de archivos no fue óptima (pero esto podría haber cambiado).Mercurial no admite fusiones de pulpos (con más de dos padres).
Por lo que he oído y leído principal Bazar Las ventajas son el fácil soporte para el flujo de trabajo centralizado (lo cual también es una desventaja, con conceptos centralizados visibles donde no deberían), el seguimiento de cambios de nombre tanto de archivos como de directorios.
Su principal desventaja es el rendimiento y el tamaño del repositorio para repositorios grandes con un largo historial no lineal (el rendimiento mejoró al menos para repositorios no demasiado grandes), el hecho de que el paradigma predeterminado es un rancho por repositorio (aunque puedes configurarlo para compartir datos) y conceptos centralizados (pero eso también por lo que he escuchado cambia).
Git está escrito en C, scripts de shell y Perl, y se puede programar;Mercurial está escrito en C (núcleo, para rendimiento) y Python, y proporciona API para extensiones;Bazaar está escrito en Python y proporciona API para extensiones.
Al considerar cada uno de ellos entre sí y con sistemas de control de versiones como SVN y Perforce, ¿qué cuestiones se deben considerar?
Los sistemas de control de versiones como Subversion (SVN), Perforce o ClearCase son centralizado Sistemas de control de versiones.Git, Mercurial, Bazaar (y también Darcs, Monotone y BitKeeper) son repartido Sistemas de control de versiones.Los sistemas de control de versiones distribuidos permiten una gama mucho más amplia de flujos de trabajo.Permiten utilizar "publicar cuando esté listo".Tienen mejor soporte para bifurcaciones y fusiones, y para flujos de trabajo con muchas ramas.No es necesario confiar en personas con acceso de compromiso para poder obtener contribuciones de ellos de manera sencilla.
Al planificar una migración de SVN a uno de estos sistemas de control de versiones distribuidos, ¿qué factores consideraría?
Uno de los factores que quizás desee considerar es el soporte para interactuar con SVN;Git tiene git-svn, Bazaar tiene bzr-svn y Mercurial tiene la extensión hgsubversion.
Descargo de responsabilidad: Soy usuario de Git y colaborador de poca monta, y miro (y participo en) la lista de correo de git.Conozco Mercurial y Bazaar sólo por su documentación, varias discusiones sobre IRC y listas de correo, y publicaciones de blogs y artículos que comparan varios sistemas de control de versiones (algunos de los cuales se enumeran en Comparación de Git página en Git Wiki).
InfoQ tiene una buena comparación.
Mercurial y Bazaar se parecen mucho en la superficie.Ambos proporcionan control básico de versiones distribuidas, como en la confirmación fuera de línea y la fusión de múltiples ramas, ambos están escritos en Python y son más lentos que git.Hay muchas diferencias una vez que profundizas en el código, pero, para tus tareas rutinarias del día a día, son efectivamente iguales, aunque Mercurial parece tener un poco más de impulso.
Git, bueno, no es para no iniciados.Es mucho más rápido que Mercurial y Bazaar y fue escrito para administrar el kernel de Linux.Es el más rápido de los tres y también el más potente de los tres, con bastante diferencia.Las herramientas de manipulación de registros y confirmaciones de Git no tienen comparación.Sin embargo, también es el más complicado y el más peligroso de utilizar.Es muy fácil perder una confirmación o arruinar un repositorio, especialmente si no comprendes el funcionamiento interno de git.
Eche un vistazo a la comparación realizada recientemente por los desarrolladores de Python: http://wiki.python.org/moin/DvcsComparison.Eligieron Mercurial por tres razones importantes:
La elección de Mercurial se tomó por tres razones importantes:
- Según una pequeña encuesta, los desarrolladores de Python están más interesados en usar Mercurial que en Bazaar o GIT.
- Mercurial está escrito en Python, lo cual es congruente con la tendencia de los desarrolladores de Python de "comerse su propia comida para perros".
- Mercurial es significativamente más rápido que bzr (es más lento que git, aunque por una diferencia mucho menor).
- Mercurial es más fácil de aprender para los usuarios de SVN que Bazaar.
Estuve usando Bazaar por un tiempo y me gustó mucho, pero solo eran proyectos más pequeños y aun así era bastante lento.Muy fácil de aprender, pero no súper rápido.Sin embargo, es muy plataforma X.
Actualmente uso Git el cual me gusta mucho ya que la versión 1.6 lo hizo mucho más parecido a otros VCS en cuanto a los comandos a usar.
Creo que las principales diferencias según mi experiencia en el uso de DVCS son las siguientes:
- Git tiene la comunidad más vibrante y es común ver artículos sobre Git.
- GitHub realmente mola.Launchpad.net está bien, pero nada como el placer de Github
- La cantidad de herramientas de flujo de trabajo para Git ha sido excelente.Está integrado por todas partes.Hay algunos para Bzr, pero no tantos ni tan bien mantenidos.
En resumen, Bzr fue genial cuando me estaba iniciando en DVCS, pero ahora estoy muy contento con Git y Github.
Esta es una gran pregunta que depende mucho del contexto y que te llevaría mucho tiempo escribir en uno de estos pequeños cuadros de texto.Además, los tres parecen sustancialmente similares cuando se usan para las cosas habituales que hacen la mayoría de los programadores, por lo que incluso comprender las diferencias requiere un conocimiento bastante esotérico.
Probablemente obtendrá respuestas mucho mejores si puede dividir su análisis de estas herramientas hasta el punto en el que tenga preguntas más específicas.
Bazaar es, en mi humilde opinión, más fácil de aprender que git.Git tiene un buen soporte en github.com.
Creo que deberías intentar utilizar ambos y decidir cuál te conviene más.
¿Cuáles ven la gente aquí como las fortalezas y debilidades relativas de Git, Mercurial y Bazaar?
Esta es una pregunta muy abierta, que raya en el cebo flameante.
Git es el más rápido, pero los tres son lo suficientemente rápidos.Bazaar es el más flexible (tiene soporte transparente de lectura y escritura para repositorios SVN) y se preocupa mucho por la experiencia del usuario.Mercurial está en algún punto intermedio.
Los tres sistemas tienen muchos fanboys.Personalmente soy un fanático de Bazaar.
Al considerar cada uno de ellos entre sí y con sistemas de control de versiones como SVN y Perforce, ¿qué cuestiones se deben considerar?
Los primeros son sistemas distribuidos.Estos últimos son sistemas centralizados.Además, Perforce es propietario mientras que todos los demás son gratuitos. como en el habla.
Centralizado versus descentralizado es una elección mucho más trascendental que cualquiera de los sistemas que mencionó dentro de su categoría.
Al planificar una migración de SVN a uno de estos sistemas de control de versiones distribuidos, ¿qué factores consideraría?
Primero, la falta de un buen sustituto para TortoiseSVN.Aunque Bazaar está trabajando por su cuenta. Variante de tortuga, pero aún no ha llegado a ese punto, en septiembre de 2008.
Luego, capacitar a las personas clave sobre cómo el uso de un sistema descentralizado afectará su trabajo.
Finalmente, la integración con el resto del sistema, como los rastreadores de problemas, el sistema de compilación nocturna, el sistema de prueba automatizado, etc.
Su principal problema será que estos son Repartido Los SCM y, como tales, requieren un pequeño cambio en la mentalidad del usuario.Una vez que la gente se acostumbre a la idea, los detalles técnicos y los patrones de uso encajarán, pero no subestime ese obstáculo inicial, especialmente en un entorno corporativo.Recuerde, todos los problemas son problemas de personas.
ddaa.myopenid.com lo mencionó de pasada, pero creo que vale la pena mencionarlo nuevamente:Bazaar puede leer y escribir en repositorios SVN remotos.Eso significa que podrías usar Bazaar localmente como prueba de concepto mientras el resto del equipo todavía usa Subversion.
EDITAR:Casi todas las herramientas ahora tienen alguno forma de interactuar con SVN, pero ahora tengo experiencia personal que git svn obras extremadamente Bueno.Lo he estado usando durante meses, con mínimos contratiempos.
Hay un buen video de Linus Torvalds en git.Él es el creador de Git, así que esto es lo que promueve, pero en el video explica qué son los SCM distribuidos y por qué son mejores que los centralizados.Hay muchas comparaciones entre git (se considera que mercurial está bien) y cvs/svn/perforce.También hay preguntas de la audiencia sobre la migración a SCM distribuido.
Este material me pareció esclarecedor y me vendieron a SCM distribuido.Pero a pesar de los esfuerzos de Linus, mi elección es voluble.La razón es bitbucket.org, lo encontré mejor (más generoso) que github.
Necesito decir aquí una palabra de advertencia:Linus tiene un estilo bastante agresivo, creo que quiere ser gracioso pero no me reí.Aparte de eso, el vídeo es excelente si eres nuevo en los SCM distribuidos y estás pensando en pasar de SVN.
Los sistemas de control de versiones distribuidos (DVCS) resuelven problemas diferentes a los VCS centralizados.Compararlos es como comparar martillos y destornilladores.
VCS centralizado Los sistemas están diseñados con la intención de que exista una Fuente Verdadera que sea Bendita y, por lo tanto, Buena.Todos los desarrolladores trabajan (compran) 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 CVCS está en el flujo de trabajo, el rendimiento y la integración que ofrece cada producto.
VCS distribuido Los sistemas 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 sobre en qué repositorio se debe confiar es impuesto desde afuera 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 quiere un control centralizado, entonces un DVCS no es un buen comienzo.Si se espera que sus desarrolladores trabajen en todo el país/mundo, sin conexiones de banda ancha seguras a un repositorio central, entonces DVCS probablemente sea su salvación.Si necesitas ambos, estás jodido.
