2012-03-12 14 views
9

He estado trabajando con Mercurial ahora por algún tiempo. Al hacer cambios (privados) en software de terceros, en el pasado siempre creé una rama con nombre diferente para estos cambios. Cuando se actualiza el código original, simplemente lo fusiono en mi rama nombrada.MQ vs. sucursales en Mercurial

Hoy he leído sobre MQ (Colas Mercurial - capítulos 12 y 13). Creo que entendí el concepto detrás de MQ, entonces mi pregunta es:

¿Hay alguna ventaja de MQ sobre las sucursales (nombradas) en Mercurial (para mi escenario)?

Respuesta

13

La principal ventaja de MQ sobre ramas nombradas son:

  • Puede revisar sus parches. Esto le permite editar el historial y así puede mantener una serie limpia y lógica de parches encima del código de flujo ascendente: si nota un error en un parche, actualice el parche en lugar de realizar un nuevo compromiso.

  • Los cambios en sus parches se separarán limpiamente de los cambios realizados anteriormente. Cuando fusionas dos ramas, mezclas las dos corrientes de desarrollo. Esto hace que sea difícil ver los cambios que ha realizado sin ver también los cambios provenientes de la rama ascendente.

  • Los nombres de los parches son transitorios. Cuando hg qfinish aplica un parche, no hay rastro del nombre del parche que queda en la confirmación. De modo que puede usar MQ sin coordinar primero con el repositorio en sentido ascendente ya que nunca notará MQ.

  • Evita las fusiones. En lugar de fusionarse con el código más reciente de la versión anterior, rebase sus parches aplicados. Esto te da una historia más simple. La historia es obviamente falsa ya que pretendes haber hecho todos tus parches después de ver el código desde la cadena ascendente - cuando de hecho lo hiciste en paralelo con la cadena ascendente y luego moviste tus parches a la punta de la cadena ascendente.

  • No tiene un nombre de sucursal permanente en los conjuntos de cambios. Las personas a veces treat named branches as disposable y se molestan cuando se dan cuenta de que una rama con nombre se ha arreglado en la historia. (En realidad se puede establecer el nombre de la sucursal con hg branch antes de empujar parches por lo que este punto no es tan malo.)

desventajas de MQ son:

  • Es una herramienta adicional para aprender.Es poderoso, pero también te da más oportunidad de dispararte en el pie. Ejecutando hg qdelete realmente eliminar el parche y por lo que puede tirar la información. (Creo que esto está bien, pero hemos tenido un usuario de Git que viene a nuestra lista de correo quejándose de esto.)

  • Hace mucho más difícil colaborar con otros. Usted puede convertir .hg/patches en un repositorio y empujar/tirar parches entre los repositorios, pero es difícil hacer eso si usted es más que un solo desarrollador. El problema es que terminas fusionando parches si más de una persona actualiza el mismo parche.

  • No tiene un nombre de sucursal permanente en los conjuntos de cambios. Si está usando ramas con nombre correcto y usa nombres de rama estables y de largo plazo, entonces lo echará de menos al usar MQ.

+0

Sin embargo, puede lograr los mismos resultados con rebase. –

+0

@LaurensHolst: oh, sí. Me enfocaba más en cómo MQ * obliga * a no volver a establecer los parches: la fusión no está permitida con MQ. Déjame expandir la respuesta un poco. –

+0

Extensión MQCollab hacer colaboración por MQ-patches * realmente agradable * –

1

Buena pregunta. Depende. Personalmente no me gusta el sistema de ramificación mercurial, y trato de evitarlo cuando puedo (usando marcadores insertados en lugar de ramificación).

MQ es una gran herramienta, con gran potencia y grandes dificultades. También puede considerar usar pbranch.

MQ es una gran herramienta si necesita producir y mantener un conjunto de parches para un proyecto, algo así como agregar feature-x a un proyecto y mantener los parches actualizados con el código upstream.

Los marcadores (o las ramas si lo desea) son útiles para las tareas de desarrollo corto que deben fusionarse en el código de flujo ascendente.