Mercurial Release Management

Question

Sto usando mercurial per il controllo del codice sorgente. Voglio avere un ramo dev principale, e poi avere punti nel tempo che si allineano con dire "v1.0" "v1.01" e "v2.0", in modo che in qualsiasi momento posso tirare giù dire "v2.0 "e schiacciare alcuni bug su di esso. Ho sentito alcune persone dire che ho bisogno di tag, alcuni dicono che ho bisogno di segnalibri, altri dicono che ho bisogno di rami nominati, e altri ancora dicono che ho solo bisogno di mantenere più repository clonati. Dal mio punto di vista, più repository clonati sembrano una scelta sbagliata perché una cosa che mi piace di DVCS è che una volta clonato il repository "the", hai tutta la cronologia passata e puoi ripristinare totalmente da qualcuno laptop se la tua centrale il server brucia. Se il repository è suddiviso in tutto il luogo, mi sembra di perdere questo vantaggio, a meno che non ci si aspetti che le persone clonino 5 repository e li mantengano sul proprio computer localmente. Questo mi preoccupa perché la maggior parte della gente dice che questo è un buon modo per farlo, ma logicamente non ha senso per me. (Capisco che questo non è un modo corretto per fare i backup, ma non avere il pieno accesso a una parte del repository senza tornare al server mi sembra strano)

Quindi per me, il modo di tenere tutto insieme deve essere tag, rami nominati o segnalibri. Tuttavia, non riesco a differenziarli. Le persone tendono a spiegare i segnalibri come "un po 'come i tag, con qualche avvertimento" e le diramazioni nominate come una sorta di tag in movimento che è probabilmente fatto meglio con i cloni.

Mi piace molto il branching di stile git (singolo repo, più rami al di fuori di esso), tuttavia, non voglio ricorrere a plugin o hack strani per renderlo simile a git. Voglio capire il giusto modo mercuriale.

Bonus: in che modo i rami "in scala ridotta" si inseriscono nel mix, cioè si desidera lavorare su una piccola funzionalità nel proprio ramo?

Answer 1

DVCS come Mercurial o Git semplifica la clonazione di un repository. Ciò non significa che lo si utilizza per finalità del flusso di lavoro di gestione del rilascio.

Che ognuno abbia un completo repo mercuriale è solo un effetto collaterale di DVCS. Significa che c'è una ridondanza quando il repository principale è un po 'perso.

È possibile lavorare con DVCS in modo da poter disporre di un repository principale in cui è possibile inviare modifiche e apportare modifiche, proprio come un VCS client-server (subversion) con il vantaggio aggiuntivo di poter lavorare offline.

Per il flusso di lavoro di gestione delle release, si dovrebbe comunque guardare

1. segnalibri, tag e rami.

Ci sono abbastanza discussioni su SO su ciascuno di questi argomenti.

• Mercurial: Named Branches vs Multiple Repositories

che segue fornisce una buona informazione breve su ramificazione con il clone, segnalibro e denominate rami

• http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/

Answer 2

nome Branch - in ogni commit fate c'è un campo per il quale il commit è contrario. Oltre a ciò non vi è alcuna differenza tra un repository con un ramo denominato e un repository con più teste.Quando si uniscono i rami nominati, si tratta di una fusione regolare e il nome del ramo viene preso dal ramo attualmente attivo. Questo è più che probabile ciò che si desidera per il ramo v1.x a lungo termine.

segnalibri - tag fluttuanti molto simili a tip nel repository. Solo locale, a meno che non si esegua una sorta di sincronizzazione della banda laterale. Buono per fare branching di funzionalità o qualcosa in cui è necessario tenere traccia di ciò che sta accadendo, ma non è necessario condividere con gli altri.

Tag - Un nome commit bene se avete bisogno di sapere esattamente ciò che è stato rilasciato alla v1.0

userei nome rami per lo sviluppo di un ramo 1.x un ramo 2.x ecc Quindi utilizzare un tag per etichettare ciò che effettivamente è uscito come versione 1.0, 1.1 sarebbe stato fatto sulla struttura 1.x, quindi 1.1 release sarebbe stato un tag di ciò che conteneva. Non vorrei rendere i bookmark parte del flusso poiché devi sincronizzarli manualmente. (Nota nelle versioni più recenti dei bookmark mercurial possono essere sincronizzati da remoto anche se richiede ancora l'intervento dell'utente.)

Answer 3

Non ho mai capito l'idea di avendo repository clonati come filiali anonime.

hg branch feature-name è come mi piace rotolare.

Answer 4

Sto usando mercurial per il controllo del codice sorgente. Voglio avere un ramo dev principale, e poi avere punti nel tempo che si allineano con dire "v1.0" "v1.01" e "v2.0", in modo che in qualsiasi momento posso tirare giù dire "v2.0 "e schiacciare alcuni bug su di esso.

Si consiglia di contrassegnare ogni versione di rilascio.

Se è necessario rilasciare una correzione di bug per una versione precedente, è necessario prima creare un ramo denominato o clonare un nuovo repository basato sul tag della versione. Una volta che hai risolto il bug, unirai il bug fix al tuo ramo di sviluppo principale.

Non importa se si utilizza un ramo o un clone con nome poiché il risultato è lo stesso: il bug è corretto, la correzione viene rilasciata alla versione precedente, la correzione è incorporata nel ramo di sviluppo principale. Leggi other answers, prova entrambi i metodi e usa quello che preferisci. Personalmente, io uso i rami nominati per questi rami di rilascio di lunga durata in modo che tutta la cronologia di ogni versione dell'applicazione sia archiviata in un singolo repository.

Quindi ... etichettare ogni release e ramo "su richiesta".

Answer 5

Sono necessari tag per contrassegnare i rilasci di v1.0, v1.01 e v2.0 ecc. Per lo sviluppo ramificato (bugfixing, feature branch, ecc.), È possibile utilizzare i segnalibri - sono ormai molto bene supportato in uso collaborativo (vedere). Se è necessario disporre di filiali di lunga durata (vale a dire che si troveranno nel repository per il futuro prevedibile), utilizzare i rami denominati. Sarebbero una buona scelta, ad es. per avere v1, v2, ... rami di sviluppo.

Si potrebbe utilizzare esclusivamente i segnalibri o rami con nome esclusivamente per entrambi rami di breve durata e di lunga durata, ma sta diventando una pratica standard a preferire i segnalibri quando si può.

Vedere anche mercurial: mix named branches and bookmarks per una risposta rapida e grafica su come i segnalibri e i rami nominati sono diversi.