: spostamento di un bug fix/miglioramento del codice attorno allo sviluppo di feature

Question

Ho una domanda relativa al flusso di lavoro relativa a Mercurial (probabilmente applicabile ad altri DVCS).

Il repository è impostato utilizzando la tipica impostazione predefinita/stabile.

Hai il compito di creare una nuova funzione e aspettare che ci voglia un po 'di tempo (mese +). Mentre si lavora su questa funzione, si incontra un bug che si ritiene debba essere corretto e applicato alla produzione prima possibile. O forse, noti qualche codice che potrebbe essere meglio documentato.

Il mio presupposto è che si esegue la correzione in modo predefinito e quindi si passa a stabile e si effettua di nuovo la correzione (manualmente o applicando una patch). È corretto o dovresti passare immediatamente alla versione stabile, apportare le modifiche lì e quindi unire stable in default?

L'utilizzo di una patch sembra avere più senso per me. È possibile effettuare un commit specifico per la correzione di bug e applicare tale patch a proprio piacimento. Voglio dire se il bug non è troppo brutto, non c'è bisogno di urgenza e di rompere il flusso. Destra?

Quindi, come gestite questa situazione?

Grazie

Answer 1

Si può tornare al punto di diramazione (revisione B), risolvere il bug esiste (revisione X) e quindi unire la correzione in entrambi i rami (M1 e M2):

-----B--o----o---M1----o---> stable 
    |  /
    |---------X bugfix 
    |   \ 
    \--o---o----M2----o-----> feature 

In questo modo è possibile ottenere la correzione in ogni ramo con le normali operazioni hg merge; non sono necessari patching, trapianti o MQ'ing.

Prendendo la stessa idea un ulteriore passo: si potrebbe invece tornare alla revisione che ha introdotto il bug in primo luogo. Usando questo come base per la correzione, sarai sicuro di poter unire la tua correzione in qualsiasi ramo che contiene il bug.

Answer 2

volta che avete fatto il vostro piccolo fix impegnano, è possibile utilizzare il Hg Transplant Extension e la relazione che lo stesso correzione su un altro ramo.

Se ciò non è appropriato, altre possibilità di selezione della ciliegia sono dettagliate nella domanda SO "Mercurial cherry picking changes for commit".