¿Cuáles son las fortalezas y debilidades relativas de Git, Mercurial y Bazar?
¿Qué ven las personas aquí como las fortalezas y debilidades relativas de Git, Mercurial y Bazar?
Al considerar a cada uno de ellos entre sí y en contra de los sistemas de control de versiones como SVN y Perforce, ¿qué problemas deberían considerarse?
Al planificar una migración de SVN a uno de estos sistemas de control de versiones distribuidos, ¿qué factores consideraría?
Git es muy rápido, se escala muy bien y es muy transparente sobre sus conceptos. El lado negativo de esto es que tiene una curva de aprendizaje relativamente empinada. Un puerto Win32 está disponible, pero no es un ciudadano de primera clase. Git expone los hashes como números de versión a los usuarios; esto proporciona garantías (porque 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 los contenidos de los archivos, incluso cuando esos contenidos se mueven entre los archivos y los ve como objetos de primer nivel, pero no rastrea los directorios. Otro problema con git es que tiene muchas operaciones (como rebase) que facilitan la modificación de la historia (en cierto sentido, el contenido al que hace referencia un hash nunca cambiará, pero las referencias a ese hash pueden perderse); A algunos puristas (yo incluido) no les gusta mucho eso.
Bazaar es razonablemente rápido (muy rápido para árboles con historia poco profunda, pero actualmente se escala poco con la longitud del historial), y es fácil de aprender para aquellos familiarizados con las interfaces de línea de comando 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 funciones (como un mejor soporte para la integración con sistemas de control de revisión basados en diferentes conceptos) y mejorar el rendimiento. El equipo de Bazaar considera que el seguimiento de directorios y el cambio de nombre son compatibles con la funcionalidad de primera clase. Si bien los identificadores de identificación de revisión únicos en todo el mundo están disponibles para todas las revisiones, se utilizan revisiones locales de árbol (números de revisión estándar, más similares a los utilizados por svn u otros SCM más convencionales) en lugar de hashes de contenido para identificar revisiones. Bazaar es compatible con "pagos ligeros", en los que el historial se guarda en un servidor remoto en lugar de copiarlo en el sistema local y se hace referencia automáticamente a través de la red cuando es necesario; en la actualidad, esto es único entre los DSCMs.
Ambos tienen algún tipo 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 back-end 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 mucho más pulido; yo fuertemente recomienda su uso sobre el de git-svn cuando el presupuesto y las restricciones de licencia lo permitan].
No he usado Mercurial ampliamente, por lo que no puedo comentarlo en detalle, excepto para señalar que, como Git, tiene direccionamiento de hash de contenido para las revisiones; también como Git, no trata a 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 a excepción de Git, y tiene una integración mucho mejor [IDE (especialmente para Eclipse) que cualquiera de sus competidores. Dadas sus características de rendimiento (que se quedan ligeramente por detrás de las de Git) y su plataforma multiplataforma superior y su soporte IDE, Mercurial puede ser atractivo 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 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 secuencias de comandos previas con SVN (es decir, requiere que pasen las pruebas unitarias antes de que pueda realizarse una confirmación), es probable que desee utilizar una herramienta similar a PQM para automatizar las solicitudes de fusión a sus sucursales compartidas.
SVK es un DSCM que utiliza Subversion como su tienda de respaldo, y tiene una integración bastante buena con las herramientas centradas en SVN. Sin embargo, tiene características de escalabilidad y rendimiento dramáticamente peores que cualquier otro DSCM importante (incluso Darcs), y debe evitarse para proyectos que puedan crecer en términos de longitud de historial o número de archivos.
[Acerca del autor: uso Git y Perforce para el trabajo, y Bazaar para mis proyectos personales y como una biblioteca integrada; Otras partes de la organización de mi empleador usan Mercurial en gran medida. En una vida anterior construí una gran cantidad de automatización alrededor de SVN; antes de eso tengo experiencia con GNU Arch, BitKeeper, CVS y otros. Al principio, Git era bastante desagradable: se sentía como GNU Arch en la medida en que era un entorno de conceptos pesados, a diferencia de los kits de herramientas diseñados para ajustarse a los flujos de trabajo elegidos por el usuario, pero desde entonces ven a estar bastante a gusto con eso].
El proyecto de Steve Streeting del Proyecto Ogre 3D acaba de publicarse una entrada de blog sobre este tema en la que hace un gran e incluso entregado comparación de Git, Mercurial y Bazar .
Al final, encuentra fortalezas y debilidades con los tres y ningún ganador claro. En el lado positivo, él te da una gran mesa para ayudarte a decidir cuál ir con.
Es una lectura corta y lo recomiendo altamente.
¿Qué ven las personas aquí como las fortalezas y debilidades relativas de Git, Mercurial y Bazar?
En mi opinión Git la fuerza es su diseño subyacente limpio y su conjunto de características muy rico. También creo que es el mejor soporte para repositorios de múltiples sucursales y para la gestión de flujos de trabajo pesados en sucursales. Es muy rápido y tiene un tamaño de repositorio pequeño.
Tiene algunas características que son útiles pero requieren un poco de esfuerzo para ser utilizadas. Entre ellas se incluyen visible intermedia intermedia ara (í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, comitamiento incremental y comit con árbol sucio; detectando cambia el nombre y copia usando heurística de similitud en lugar de rastrearlos usando algún tipo de identificadores de archivos, que funciona bien y que permite la culpa (anotación) que puede seguir el movimiento del código a través de los archivos y No solo nombres al por mayor.
Una de sus desventajas es que el soporte de MS Windows se queda atrás y no está completo. Otra desventaja percibida es que no está tan bien documentada como, por ejemplo, Mercurial, y es menos fácil de usar que la competencia, pero cambia.
En mi opinión la fuerza de Mercurial radica en su buen rendimiento y su pequeño tamaño de repositorio, en su buena compatibilidad con MS Windows.
El principal inconveniente es, en mi opinión, el hecho de que las sucursales locales (múltiples sucursales en un solo repositorio) siguen siendo ciudadanos de segunda clase, y de manera extraña y complicada implementa etiquetas. También la forma en que se ocupa de los nombres de los archivos era subóptima (pero este migth ha cambiado). Mercurial no admite la fusión de pulpos (con más de dos padres).
Por lo que he escuchado y leído, las ventajas principales 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 ), rastreando nombres de archivos y directorios.
Su principal desventaja es el rendimiento y el tamaño del repositorio para grandes repositorios con un largo historial no lineal (el rendimiento mejoró al menos para los repositorios no demasiado grandes), el hecho de que el paradigma predeterminado es un rancho por repositorio (puede configurarlo para compartir datos, sin embargo) , y conceptos centralizados (pero eso también por lo que he escuchado cambios).
Git está escrito en C, Shell scripts y Perl, y es compatible con scripts; 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 en contra de los sistemas de control de versiones como SVN y Perforce, ¿qué problemas deberían considerarse?
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 distribuidos permiten una mayor variedad de flujos de trabajo. Permiten utilizar "publicar cuando esté listo". Tienen mejor soporte para ramificación y fusión, y para flujos de trabajo pesados de ramificación. No es necesario que confíe en personas con acceso comprometido para poder obtener contribuciones de ellos de una manera fácil.
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 podría querer considerar es el soporte para entrar en contacto 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 tiempo reducido, y veo (y participo en) la lista de correo de git. Conozco Mercurial y Bazaar solo por su documentación, varias discusiones sobre IRC y listas de correo, y publicaciones de blog y artículos que comparan varios sistemas de control de versiones (algunos de los cuales están listados en GitComparison página en Git Wiki).
InfoQ tiene na buena comparación .
Mercurial y Bazar se asemejan mucho en la superficie. Ambos proporcionan un control de versión distribuido básico, como en la confirmación sin conexión y la combinación de varias ramas, están escritos en python y son más lentos que git. Hay muchas diferencias una vez que profundiza en el código, pero para sus tareas cotidianas de rutina, son efectivamente 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 registro y compromiso de Git no tienen igual. 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 repositorio, especialmente si no entiendes el funcionamiento interno de git.
Echa 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 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 Bazaar o Git.
- Mercurial está escrito en Python, que es congruente con la tendencia de python-dev a "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 Bazaar.
Estuve usando Bazaar durante un tiempo, lo cual me gustó mucho, pero solo eran proyectos más pequeños e incluso entonces era bastante lento. Tan fácil de aprender, pero no super rápido. Aunque es muy x-plataforma.
Actualmente utilizo Git, que me gusta mucho ya que la versión 1.6 lo hizo mucho más similar a otros VCS en términos de los comandos a usar.
Creo que las principales diferencias de 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 rocas. Launchpad.net está bien, pero nada como el placer de Github
- El número de herramientas de flujo de trabajo para Git ha sido excelente. Está integrado por todo el lugar. Hay algunos para Bzr pero no tanto o tan bien mantenidos.
En resumen, Bzr fue genial cuando me estaba cortando los dientes con DVCS pero ahora estoy muy feliz con Git y Github.
Su principal problema será que estos son Distribuido SCM, y como tales requieren un poco de un 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 se ubicarán en su lugar, pero no subestime ese obstáculo inicial, especialmente en un entorno corporativo. Recuerda, todos los problemas son problemas de la gente.
El bazar es IMHO más fácil de aprender que git. Git tiene un soporte agradable en github.com.
Creo que deberías intentar usar ambos y decidir cuál te conviene más.
Esta es una gran pregunta que depende mucho del contexto que le tomarí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 tareas habituales de la mayoría de los programadores, por lo que incluso entender las diferencias requiere un cierto conocimiento bastante esotérico.
Probablemente obtendrá respuestas mucho mejores si puede desglosar su análisis de estas herramientas hasta el punto en el que tenga preguntas más específicas.
¿Qué ven las personas aquí como las fortalezas y debilidades relativas de Git, Mercurial y Bazar?
Esta es una pregunta muy abierta, bordeando 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 los repositorios 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 un fanboy de Bazar.
Al considerar a cada uno de ellos entre sí y en contra de los sistemas de control de versiones como SVN y Perforce, ¿qué problemas deberían considerarse?
Los primeros son sistemas distribuidos. Los últimos son sistemas centralizados. Además, Perforce es propietario mientras que todos los demás son gratuitos como en el discurso .
Centralizado versus descentralizado es una opció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?
En primer lugar, 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 partir de septiembre de 2008.
Luego, capacitar a las personas clave sobre cómo el uso de un sistema descentralizado va a 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.
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ía usar Bazaar localmente como una prueba de concepto mientras el resto del equipo todavía está usando Subversion.
EDITAR: Casi toda la herramienta ahora tiene alguna forma de interactuar con SVN, pero ahora tengo experiencia personal que funciona git svnextremadamente = bien Lo he estado usando durante meses, con un mínimo de hipo.
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/perforce. También hay preguntas de la audiencia con respecto a la migración a SCM distribuido.
Encontré este material esclarecedor y estoy vendido a SCM distribuido. Pero a pesar de los esfuerzos de Linus, mi elección es Mercurial. La razón es bitbucket.org, lo encontré mejor (más generoso) que github.
Necesito decir aquí una advertencia: Linus tiene un estilo bastante agresivo, creo que quiere ser gracioso, pero no me reí. Aparte de eso, el video es excelente si eres nuevo en SCM distribuidos y piensas en cambiarte de SVN.
Los sistemas distribuidos de control de versiones (DVCS) solucionan 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 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 bendecidos de manera similar. La única diferencia real entre CVS, Subversion, ClearCase, Perforce, VisualSourceSafe y todas las demás CVCSes está en el flujo de trabajo, el rendimiento y la integración que ofrece cada producto.
Distributed VCS 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 en cuanto a qué repositorio se debe confiar es impuesto desde el exterior por el proceso, no por el propio software.
La opción real entre usar un tipo u otro es organizativa: si su proyecto u organización desea un control centralizado, entonces un DVCS no es un motor de arranque. 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 ambos, estás fsck'd.