2012-04-23 11 views
11

Abbiamo due teste. Uno è il nostro principale capo dello sviluppo e l'altro è quello che ho dimenticato fino ad oggi. Abbiamo trovato un bug e l'abbiamo risolto nel nostro ramo di sviluppo principale, e ho appena realizzato che dovrebbe essere corretto anche nel ramo più vecchio.Il flusso di lavoro su "backport" viene modificato in un altro ramo Mercurial (Hg)?

Penso che sarebbe stato meglio apportare la modifica al ramo più vecchio e unirlo con il ramo aggiornato, ma non l'abbiamo fatto in quel modo. Può gestire questo mercurial? Non abbiamo provato a fare qualcosa di simile e non riesco davvero a capire come sarebbe stato fatto.

+0

http://stackoverflow.com/questions/854930/mercurial-cherry-picking-change-for-commit – zerkms

+1

Lo trovo più semplice se il "ramo di sviluppo principale" è di per sé un albero, in cui diversi cambiamenti sono a loro volta ("anonimo") rami che crescono e vengono rimessi in ... –

+3

(non una risposta, quindi il commento) * "Penso che sarebbe stato meglio apportare la modifica sul ramo più vecchio" * ...È * forse * stato ancora meglio applicare quel bugfix come una "correzione daggy": si ripristina il punto in cui è stato introdotto il bug, si commette la correzione e si fonde a monte. Applicandolo "il prima possibile" * potrebbe * essere anche meglio applicare prima al tuo "ramo più vecchio" (qualunque cosa sia). Per piccole correzioni di errori, daggy fix fa totalmente rock (IMHO): http://mercurial.selenic.com/wiki/DaggyFixes – TacticalCoder

risposta

14

Sì, si hanno due buone opzioni:

Graft: nuovo in Mercurial 2.0

Questa versione ha introdotto il graft command che può backport cambiamenti in modo intelligente. L ' "intelligenza" è che si userà unioni internamente e questo significa che si ottiene

  • Supporto per rinomina: Immaginate che si fissa il bug nel file di foo.c sul ramo di sviluppo. Nel ramo di manutenzione precedente foo.c è stato chiamato bar.c. Utilizzando hg graft, la modifica a foo.c può essere unita correttamente al vecchio bar.c.

  • Unioni a tre vie: L'innesto comprende twisting the graph around e la fusione in tale grafico temporaneo. Il vantaggio delle unioni a tre è che è possibile utilizzare il normale strumento di unione grafica per risolvere i conflitti.

Per copiare la punta di default su old-branch è sufficiente eseguire

$ hg update old-branch 
$ hg graft default 

Transplant: anziani versioni

Prima abbiamo avuto il comando di innesto, la transplant extension era la strada da percorrere. Questa semplice estensione esporterà un changeset come patch e cercherà di applicare la patch su qualche altra revisione.

Poiché abbiamo a che fare con patch "stupide", cose come la rinomina non verranno prese in considerazione e non otterrete il supporto per il vostro strumento di unione poiché non c'è un'unione a tre. Nonostante ciò, ho trovato che il trapianto funziona davvero bene nella pratica.

Utilizzando trapianto è semplice:

$ hg update old-branch 
$ hg transplant default 

Questo è molto vicino a correre

$ hg update old-branch 
$ hg export default | hg import - 

la differenza che il trapianto aggiunge anche un pezzo di meta-dati che registra il changeset originale nel changeset trapiantato. Questo può essere usato per saltare i futuri trapianti.

Problemi correlati