version control - control - Por qué Kiln se basa en Mercurial, y no en otros(D) VCS

sourcetree

Question

¿Cuál fue el motivo para elegir Mercurial como base de FogCreek Kiln , un sistema de administración de control de origen con revisión de código estrechamente integrada e integración de FogBugz?

¿Por qué Mercurial, y no otro sistema de control de versiones (distribuido), como Bazaar, Git o Monotone, o crear un sistema de control de versiones propio como Fossil (administración de configuración de software distribuido, incluyendo el seguimiento de errores y wiki)?

¿Cuáles son las características que hacen que FogCreek elija Mercurial como motor de horno?

Answer 1

Aquí hay una respuesta de uno de los desarrolladores de Kiln.

• Proporciona una ramificación real.
• Es fácil de usar
• El soporte de Windows es muy bueno.
• Es rápido.
• Es poderoso.
• Es fácilmente extensible.

Vea todos los detalles here . Se explicaron completamente.

Answer 2

Creo que el problema de hg vs. git es una pista falsa, ya que el problema de soporte del sistema operativo por sí solo es una gran diferencia. La verdadera pregunta es por qué hg en lugar de bzr, ya que estos dos son muy similares y los propios desarrolladores consideran que bzr es su competencia real y viceversa. Sun realizó una evaluación exhaustiva de ambos cuando se trataba de elegir un DVCS para OpenSolaris y OpenJDK. A uno le gustaría saber cuál fue el proceso utilizado para seleccionar hg en FogCreek. Todo lo que obtuvimos hasta ahora en forma de respuestas (aparte del problema de soporte del sistema operativo) son generalidades.

Answer 3

Cuando miré al sistema DVCS me gusta Mercurial porque.

• A los desarrolladores de Mercurial parece importarles los usuarios de Microsoft Windows.
• Los desarrolladores de Mercurial no piensan que los usuarios de Microsoft Windows sean usuarios de Unix forzados a usar Windows.
• A diferencia de muchos desarrolladores de código abierto, los desarrolladores de Mercurial no parecen odiar a Microsoft por ganar dinero.

Quizás los desarrolladores de Kiln pensaron lo mismo ...
(Todos los principales sistemas DVCS son lo suficientemente buenos, de lo contrario otros factores entrarían en juego más)

Answer 4

No puedo hablar por FogCreek, pero sé que cuando elegí qué DVCS usar mucha gente comentó que git no funciona bien en Windows (a menos que se ejecute en cygwin). Como FogBugz está diseñado para ejecutarse en sistemas Windows o Linux (por lo que entiendo, no soy un usuario), tener una capa adicional (cygwin) para ejecutar git puede haber sido el factor determinante allí. No sé mucho sobre Bazaar o Monotone, así que no puedo ofrecer ningún comentario allí.

Answer 5

Respuesta original (noviembre de 2009, GitHub tiene solo 1 año, Git solo 4)

Realmente no lo sé, pero me atrevería a decir "mejor soporte de Windows", ya que Windows es potencialmente la plataforma principal para la mayoría de sus clientes.
Git sigue siendo un producto demasiado "unix / linux", con un soporte "optimista" para Windows a través de mSysGit .
Simplemente lea el tono de algunos de los artículos de MSysGitHerald , como el noveno :

Durante mucho tiempo, msysGit fue impulsado por la pandilla formada por Hannes, Steffen, Sebastian Schuberth y yo [Johannes Schindelin]. En algún momento me sentí tan frustrado que dejé de trabajar en msysGit por completo. La razón es simple: no fue más divertido. Demasiadas personas pidieron correcciones o mejoras, y ninguno de ellos ofreció contribuciones propias. Como yo no soy una persona de Windows (siendo un usuario feliz de Linux desde 1994), el trabajo en mSysGit no fue lo suficientemente gratificante como para continuar. Entonces me detuve.
Pero mientras tanto, las cosas han cambiado.
Recibimos contribuciones de ...

Eso no inspira una gran confianza cuando se trata de impulsar esa herramienta para su jefe de TI. Estoy muy contento con Git por el uso personal, y muy agradecido por el arduo trabajo de todos los colaboradores de mSysGit, pero en una gran compañía, me sería difícil convertir a Git en la herramienta DVCS predeterminada adoptada por nuestros desarrolladores de Windows.
Tanto por la curva de aprendizaje, pero principalmente porque el nivel de soporte aún no está allí.
Esa es solo una opinión personal, y si tiene una experiencia diferente al implementar Git con éxito, más poder para usted.

Mercurial es el DVCS más cercano a Git, y se basa en scripts de Python portátiles (y no scripts sh de Linux / basados ​​en Unix), puede ser una elección pragmática.

Actualización 2018, siete años después: sí, el soporte de Windows para Git ahora es una realidad.

Y Microsoft tiene toda su base de código de Windows en un repositorio Git (gigante): consulte " El repositorio Git más grande del planeta ": archivos de 3.5M, 300GB, 4.000 ingenieros que producen 1.760 "compilaciones de laboratorio" diarias en 440 sucursales además de miles de recursos solicitar construcciones de validación
Pero esto es con la adición de GVFS (Git Virtual FileSystem) , que permite descargar dinámicamente solo las porciones que necesita en función de lo que usa.
Todavía no es nativo de Git, aunque su integración comenzó el pasado mes de diciembre de 2017, con la implementación de una clonación estrecha / parcial .

Kiln también promociona el soporte de Git :

Kiln , nuestra mejor solución de alojamiento DVCS, es compatible con Git y con Mercurial!
GitHub es genial. FogBugz es genial. ¿Qué podría ser aún mejor? ¿Qué hay de integrarlos! FogBugz puede ser notificado por GitHub Web Hooks siempre que un comentario de conjunto de cambios entrante mencione un caso.

Answer 6

Entonces ahora agregan también git:

Una de las características nuevas más importantes es Kiln Harmony, que le permite operar en repositorios de horno utilizando Git o Mercurial. De modo que puede enviar cambios a un repositorio de hornos usando Git y luego sacarlos usando Mercurial. Esto significa que nunca tendrá que decidir si desea usar Git o Mercurial.