Mercurial Patch cola de casos de uso

Question

Yo uso parches mercuriales en los siguientes casos: -

1. Cuando tenga que tirar de un repositorio remoto y tener cambios no confirmados pendientes . Entonces sólo tiene que crear un parche, qpop, tire del repositorio remoto, y luego importar el parche de nuevo.
2. Cuando necesito subir parches para reviewboards . Simplemente hago un parche y subirlo.

¿Cómo más se utiliza Mercurial Patch colas? Siento que la extensión Mercurial es una muy poderosa y que yo no estoy usando a su máximo potencial.

Answer 1

El wiki de Mercurial tiene un buena sección en casos de uso:

En resumen:

1. Almacenamiento del estado actual de la copia de trabajo para que pueda volver fácilmente a ella más tarde
2. La prevención de una "copia de trabajo enredada" - si está a medio camino a través de un cambio y quiere cambiar algo más
3. Proporcionar mutables decir, compromisos rearrangeable para que pueda obtener la 'historia' mirando justo antes de empujar.

Answer 2

realmente no necesita parches mercuriales para esto. Si tiene cambios uncommited pendientes cuando se tire, que se fusionarán con la punta.

Ejemplo:

C:\>hg init db
C:\>cd db
C:\db>echo >file1
C:\db>echo >file2
C:\db>echo >file3
C:\db>hg ci -Am codebase          # Create a code base with 3 files.
adding file1
adding file2
adding file3
C:\db>echo a change >>file2       # Outstanding change to file2.
C:\db>hg st
M file2

En este punto vamos a clonar la base de datos y publicar los cambios que podemos sacar.

C:\db>hg clone . \db2
updating to branch default
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
C:\db>cd \db2
C:\db2>echo a change >>file3
C:\db2>hg ci -m "file3 change"    # Commit a change to file3.

De vuelta en la base de datos original ...

C:\db2>cd \db
C:\db>hg st                       # Still have uncommitted change
M file2
C:\db>hg pull \db2
pulling from \db2
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
(run 'hg update' to get a working copy)
C:\db>hg st                       # We have the new history, but haven't updated.
M file2                           # file2 has uncommitted change.
C:\db>type file3                  # file3 is unchanged. 
ECHO is on.
C:\db>hg update
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
C:\db>hg st                       # We've updated, and file2 *still* has
M file2                           #    uncommitted change.
C:\db>type file2
ECHO is on.
a change
C:\db>type file3                  # But file3 now has committed change
ECHO is on.                       #    that was pulled.
a change

Así que la moraleja es, sólo puede tirar y actualizar, incluso con cambios no confirmados. Si hay conflictos de fusión, el comportamiento normal de combinación se produce así.

Para exportar parche hg export <rev> exportará parches para su revisión.

Answer 3

Cuando se crea una cola de parche en Bitbucket, se enumeran algunos de los usos comunes para las colas de parche en el panel derecho. Su explicación es muy bueno y responde a su pregunta directamente. Citas de que están por debajo.

colas de parche son buenas para:

  

  

• características en desarrollo tiene la intención de someter a la opinión aguas arriba

       

  Debido a que los parches en las colas parche puede   ser modificado, que proporcionan una forma ideal   para desarrollar una característica en una   la historia de desviarse de forma, mientras que todavía   lo que le permite incorporar fácilmente   retroalimentación

  

• Experimentando con la adición de una nueva característica

       colas

  Patch no desorden de su   la historia del proyecto, por lo que puede de manera segura   usarlos como una forma de probar rápidamente   una idea, y mantenerlo en la versión   control, sin estorbar encima de su   la historia del proyecto con fallado   excursiones. Si decide mantener el   experimento, se puede convertir fácilmente una   cola de parche en un conjunto de tradicional   compromete mercuriales

  

• Mantener las personalizaciones privadas para otro proyecto

       

  Dado que las colas de parche no son parte de   el registro de cambios oficial para un proyecto,   que son ideales para mantener privada   personalizaciones para una aguas arriba   proyecto. Por ejemplo, es posible que   mantener un parche cola que hace   programa de integrarse mejor con su   flujo de trabajo de la empresa

  

colas de parche son no bueno para

  

  

• larga duración ramas

       

  Dado que las colas de parche son altamente   volátil, que hacen un mal seguimiento de trabajos   la historia a largo plazo de su fuente   código. Por esta razón, de larga duración   ramas, tales como los que   corresponden a las versiones de los productos, debe   mantenerse en repositorios o denominación   ramas.

  

• Grupo de desarrollo

       colas

  Patch no hacen un seguimiento de combinación   la historia, lo que les hace un pobre   opción para hacer el desarrollo del grupo,   donde realmente se desea ver cuando una   determinado conjunto de características se fusionó   un repositorio. En caso de duda, se   debe mantenerse dentro de un tenedor tradicional,   pero dominar el poder de parche   colas le dará tremenda   flexibilidad en el flujo de trabajo, y   ofrecerle mucho mayor   capacidades de colaboración.

  

Answer 4

MQ es una gran herramienta para gestionar el desarrollo concurrente. Flagrante auto-plagio y la auto-promoción de mi propia :

  

3 Uso MQ con un parche (o múltiples parches consecutivos) por proyecto.

     

  
• Pros:. Simple y fácil
  
• Contras: debe qrefresh antes de la conmutación y reconstruir después; difícil   y arriesgado si los proyectos no son   ortogonal.
  

     

4 Utilice una rama MQ por proyecto.

     

  
• Pros: de ultra flexible y escalable (para el número de concurrente   proyectos)
  
• Contras: debe qrefresh y qcommit antes de la conmutación y reconstruir después;   se siente complicado.