¿Cuáles son las fortalezas y debilidades relativas de Git, Mercurial y Bazaar?

¿Qué ven aquí la gente como las fortalezas y debilidades relativas de Git, Mercurial y Bazaar?

Al considerar cada uno de ellos entre sí y contra los sistemas de control de versiones como SVN y Perforce, ¿qué problemas deberían tenerse en count?

Al planificar una migration de SVN a uno de estos sistemas de control de versiones distribuidas, ¿qué factores consideraría?

Git es muy rápido, se escala muy bien y es muy transparente con respecto a sus conceptos. La desventaja de esto es que tiene una curva de aprendizaje relativamente empinada. Un puerto Win32 está disponible, pero no es un ciudadano de primera class. Git expone hashes como numbers de versión para los usuarios; esto proporciona garantías (en el sentido de que un solo hash siempre se refiere al mismo contenido exacto, un atacante no puede modificar el historial sin ser detectado), pero puede ser engorroso para el usuario. Git tiene un concepto único de seguimiento de contenido de files, incluso cuando esos contenidos se mueven entre files y visualizan files como objects de primer nivel, pero no rastrean directorys. Otro problema con git es que tiene muchas operaciones (como rebase ) que hacen que sea fácil modificar el historial (en cierto sentido, el contenido al que hace reference un hash nunca cambiará, pero las references a ese hash pueden perderse); algunos puristas (yo incluido) no me gusta mucho.

Bazar es razonablemente rápido (muy rápido para treees con poca historia, pero actualmente escasea pobremente con la longitud del historial), y es fácil de aprender para aquellos familiarizados con las interfaces de línea de command de los SCM tradicionales (CVS, SVN, etc.). Win32 es considerado un objective de primera class por su equipo de desarrollo. Tiene una architecture conectable para diferentes componentes y reemplaza su formatting 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 performance. El equipo de Bazaar considera que el seguimiento de directorys y el cambio de nombre respaldan la funcionalidad de primera class. Mientras que los identificadores de ID de revisión únicos a nivel mundial están disponibles para todas las revisiones, se usan revnos locales (numbers de revisión estándar, más parecidos a los utilizados por svn u otros SCM más convencionales) en lugar de los hash de contenido para identificar revisiones. Bazaar tiene soporte para "cajas livianas", en las cuales la historia se guarda en un server remoto en lugar de copyrse al sistema local y se hace reference automáticamente a través de la networking 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 formatting de back-end introducidas para ese fin. [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; Recomiendo encarecidamente su uso sobre el de git-svn cuando las restricciones de presupuesto y licencias lo permitan].

No he usado Mercurial de forma exhaustiva, por lo que no puedo comentarlo en detalle, excepto para señalar que, como Git, tiene un direccionamiento hash de contenido para las revisiones; también como Git, no trata los directorys como objects de primera class (y no puede almacenar un directory vacío). Sin embargo, es más rápido que cualquier otro DSCM a exception de Git, y tiene una mejor integración IDE (especialmente para Eclipse) que cualquiera de sus competidores. Dadas sus características de performance (que están un poco por detrás de las de Git) y su superior compatibilidad multiplataforma e IDE, Mercurial puede ser convincente para equipos con un número significativo de miembros centrados en win32 o IDE.

Una preocupación al migrar desde SVN es que las interfaces gráficas de SVN y la integración de IDE son más maduras que las de cualquiera de los SCM distribuidos. Además, si actualmente hace un uso intensivo de la automation de secuencias de commands previas con SVN (es decir, que requieren pasar testings de unidades antes de que pueda continuar una confirmación), es probable que desee utilizar una herramienta similar a PQM para automatizar las requestes de fusión en sus twigs compartidas.

SVK es un DSCM que utiliza Subversion como su backing store, y tiene una integración bastante buena con las herramientas cinputs en SVN. Sin embargo, tiene características de performance y escalabilidad dramáticamente peores que cualquier otro DSCM (incluso Darcs), y debe evitarse para proyectos que pueden crecer en términos de longitud de historial o cantidad de files.

[Sobre el autor: uso Git y Perforce para el trabajo, y Bazaar para mis proyectos personales y como biblioteca integrada; otras partes de la organización de mi empleador usan mucho a Mercurial. En una vida anterior construí una gran cantidad de automation alnetworkingedor de SVN; antes de eso tengo experiencia con GNU Arch, BitKeeper, CVS y otros. Al principio, Git era bastante desalentador: se sentía como GNU Arch por ser un entorno cargado de 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 eso].

Steve Streeting del proyecto Ogre 3D acaba de publicar (28/09/2009) una input de blog sobre este tema donde hace una gran e incluso entregada 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, él ofrece una gran table para ayudarte a decidir con qué ir.

texto alternativo

Es una lectura breve y lo recomiendo encarecidamente.

InfoQ tiene una buena comparación .


¿Qué ven aquí la gente como las fortalezas y debilidades relativas de Git, Mercurial y Bazaar?

En mi opinión, la fuerza de Git es su layout subyacente limpio y su set de características muy rico. También creo que es el mejor soporte para repositorys multi-sucursales y gestión de flujos de trabajo de sucursales. Es muy rápido y tiene un pequeño tamaño de repository.

Tiene algunas características que son útiles pero requieren un esfuerzo para ser usadas. Estos incluyen el estadiaje intermedio visible ara (índice) entre el área de trabajo y la database del repository, lo que permite una mejor resolución de fusión en casos más complicados, comicios incrementales y comits con el tree sucio; detectar renombrados y copys utilizando heurística de similitud en lugar de rastrearlos usando algún tipo de ID de file, que funciona bien y que permite culpar (anotar) que puede seguir el movimiento del código a través de files y no solo cambiar el nombre al por mayor.

Una de sus desventajas es que el soporte de MS Windows está rezagado y no está lleno. Otra desventaja percibida es que no está tan bien documentada como, por ejemplo, Mercurial, y es less fácil de usar que la competencia, pero cambia.

En mi opinión, la fuerza de Mercurial radica en su buen performance y pequeño tamaño de repository, en su buen soporte de MS Windows.

La principal desventaja es, en mi opinión, el hecho de que las sucursales locales (múltiples sucursales en un repository único) siguen siendo ciudadanos de segunda class, y de manera extraña y complicada implementan tags. También la forma en que se ocupa de los cambios de nombre de file no era óptima (pero esta migration ha cambiado). Mercurial no es compatible con fusiones de pulpos (con más de dos padres).

Por lo que he escuchado y leído, las principales ventajas de Bazaar son su fácil soporte para el flujo de trabajo centralizado (que también es una desventaja, con conceptos centralizados visibles donde no debería), el seguimiento de los cambios de nombre de los files y directorys.

Su principal desventaja es el performance y el tamaño del repository para grandes repositorys con larga historia no lineal (el performance mejorado al less para repositorys no demasiado grandes), el hecho de que el paradigma pnetworkingeterminado es un rancho por repository (sin embargo, puede configurarlo para compartir datos) , y conceptos centralizados (pero eso también de lo que he escuchado cambios).

Git está escrito en C, scripts de shell y Perl, y es scripttable; Mercurial está escrito en C (core, para performance) 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 contra los sistemas de control de versiones como SVN y Perforce, ¿qué problemas deberían tenerse en count?

Los sistemas de control de versiones como Subversion (SVN), Perforce o ClearCase son sistemas de control de versiones centralizados . Git, Mercurial, Bazaar (y también Darcs, Monotone y BitKeeper) son sistemas de control de versiones distribuidos . Los sistemas de control de versiones distribuidas permiten una gama mucho más amplia de flujos de trabajo. Permiten usar "publicar cuando esté listo". Tienen un mejor soporte para la bifurcación y la fusión, y para flujos de trabajo pesados ​​en sucursales. No necesita confiar en las personas con acceso de compromiso para poder get contribuciones de ellos de una manera fácil.


Al planificar una migration de SVN a uno de estos sistemas de control de versiones distribuidas, ¿qué factores consideraría?

Uno de los factores que quizás desee considerar es el soporte para la integración con SVN; Git tiene git-svn, Bazaar tiene bzr-svn, y Mercurial tiene extensión hgsubversión.

Descargo de responsabilidad: soy usuario de Git y queueborador de poca monta, y miro (y participo en) la list de correo de git. Conozco a Mercurial y Bazaar solo a partir de su documentation, varias discusiones sobre IRC y lists de correo, y publicaciones de blogs y artículos que comparan varios sistemas de control de versiones (algunos de los cuales se enumeran en la página de GitComparison en Wiki Git).

Mercurial y Bazaar se parecen mucho en la superficie. Ambos proporcionan control básico de versión distribuida, ya que en el compromiso fuera de línea y en la fusión de varias twigs, 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 diarias, en realidad son las mismas, aunque Mercurial parece tener un poco más de impulso.

Git, bueno, no es para los 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 es el más poderoso de los tres, con bastante margen. Las herramientas de manipulación de loggings y confirmaciones de Git no tienen comparación. Sin embargo, también es el más complicado y el más peligroso de usar. Es muy fácil perder un compromiso o arruinar un repository, especialmente si no entiendes 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 en base a tres razones importantes:

La elección de ir con Mercurial se hizo por tres razones importantes:

  • Según una pequeña encuesta, los desarrolladores de Python están más interesados ​​en usar Mercurial que en Bazar o Git.
  • Mercurial está escrito en Python, que es congruente con la tendencia python-dev de 'comer 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 Bazar.

(de http://www.python.org/dev/peps/pep-0374/ )

Sun hizo una evaluación de git , Mercurial y Bazaar como candidatos para replace Sun Teamware VCS por la base de código de Solaris. Me pareció muy interesante.

Esta es una gran pregunta que depende mucho del context que le llevaría mucho time escribir en uno de estos pequeños cuadros de text. Además, los tres de estos parecen sustancialmente similares cuando se utilizan para las cosas habituales que la mayoría de los progtwigdores hacen, por lo que incluso la comprensión de las diferencias requiere un poco de conocimiento bastante esotérico.

Probablemente obtendrá mejores respuestas si puede desglosar el análisis de estas herramientas hasta el punto en que tiene preguntas más específicas.

Bazar es IMHO más fácil de aprender que git. Git tiene un buen soporte en github.com.

Creo que deberías tratar de usar ambos y decidir cuál te conviene más.

¿Qué ven aquí la gente como las fortalezas y debilidades relativas de Git, Mercurial y Bazaar?

Esta es una pregunta muy abierta, que raya en flamebait.

Git es el más rápido, pero los tres son lo suficientemente rápidos. Bazaar es el más flexible (tiene soporte de lectura y escritura transparente para repositorys SVN) y se preocupa mucho por la experiencia del usuario. Mercurial está en algún lugar en el medio.

Los tres sistemas tienen muchos fanboys. Personalmente soy fanático del Bazar.

Al considerar cada uno de ellos entre sí y contra los sistemas de control de versiones como SVN y Perforce, ¿qué problemas deberían tenerse en count?

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 opción mucho más trascendental que cualquiera de los sistemas que mencionas dentro de su categoría.

Al planificar una migration de SVN a uno de estos sistemas de control de versiones distribuidas, ¿qué factores consideraría?

Primero, la falta de un buen sustituto para TortoiseSVN. Aunque Bazaar está trabajando en su propia variante de tortuga , pero aún no está allí, a partir de septiembre de 2008.

Luego, capacite a las personas key sobre cómo el uso de un sistema descentralizado afectará su trabajo.

Finalmente, integración con el rest del sistema, como los rastreadores de problemas, el sistema de compilation nocturno, el sistema de testing automatizado, etc.

Una cosa que falta muy importante en el bazar es cp. No puede tener múltiples files compartiendo el mismo historial, como lo ha hecho en SVN, vea por ejemplo aquí y aquí . Si no planea usar cp, bzr es un reemploop excelente (y muy fácil de usar) para svn.

Estuve usando Bazar durante un time, lo que me gustó mucho, pero solo se trataba de proyectos más pequeños y, aun así, fue bastante lento. Tan fácil de aprender, pero no súper rápido. Sin embargo, es muy x-plataforma.

Actualmente uso Git, que me gusta mucho desde que la versión 1.6 lo hizo mucho más similar a otros VCS en cuanto a los commands que se usan.

Creo que las principales diferencias para mi experiencia en el uso de DVCS es esta:

  1. Git tiene la comunidad más vibrante y es común ver artículos sobre Git
  2. GitHub realmente rocas. Launchpad.net está bien, pero nada como el placer de Github
  3. La cantidad de herramientas de flujo de trabajo para Git ha sido excelente. Está integrado en todo el lugar. Hay algunos para Bzr pero no tanto o tan bien mantenidos.

En resumen, Bzr fue genial cuando estaba aprendiendo a DVCS, pero ahora estoy muy contento con Git y Github.

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 performance y la integración que ofrece cada producto.

Los sistemas distribuidos de VCS están diseñados con la intención de que un repository sea tan bueno como cualquier otro, y que las fusiones de un repository 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 process, 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 repository central, entonces DVCS es probablemente su salvación. Si necesitas ambas, estás fsck'd.

Su principal problema será que estos son SCM Distribuidos , y como tales requieren un poco de 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 en su lugar, 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 de nuevo: Bazaar puede leer y escribir en repositorys SVN remotos. Eso significa que puede usar Bazar localmente como una testing de concepto mientras el rest del equipo todavía usa Subversion.

EDITAR: Prácticamente toda la herramienta ahora tiene alguna forma de interactuar con SVN, pero ahora tengo experiencia personal de que git svn funciona extremadamente bien. Lo he estado usando durante meses, con un mínimo de contratimes.

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 una buena cantidad de comparación de git (se considera que mercurial está bien) y cvs / svn / forzado. También hay preguntas de la audiencia con respecto a la migration a SCM distribuido.

Encontré este material esclarecedor y me venden a SCM distribuido. Pero a pesar de los esfuerzos de Linus, mi elección es mercurial. El motivo 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 yo no me reí. Además, el video es excelente si eres nuevo en los SCM distribuidos y piensas en moverte de SVN.

http://www.youtube.com/watch?v=4XpnKHJAok8