Qual è il modo migliore per chiudere un ramo Mercurial?

Question

È meglio chiudere prima un ramo e quindi unirlo con il ramo predefinito (per esempio) o prima unirlo e quindi chiuderlo?

In TortoiseHg, ad esempio, nel primo caso, vedrai una linea da un nodo vicino al ramo predefinito. Nel secondo caso vedrai una linea dall'ultimo commit al ramo predefinito e una linea extra dall'ultimo commit a un nodo chiuso.

Spero di essere chiaro. Forse è una questione di gusti ...

Answer 1

Non c'è alcuna differenza reale tra i due metodi quando si parla di rami nominati, almeno in qualsiasi versione recente di Mercurial. Le cose erano diverse pre-1.5 (?), Ma puramente nel fatto che hg heads e hg branches includevano questi rami "chiusi" nella loro uscita - possono ancora se si specifica -c sul comando.

Ricorda che quando chiudi una diramazione (usando hg commit --close-branch o in Tortoise), in effetti, ti impegni a creare un nuovo changeset in cui la modifica ha un flag impostato per dire che il ramo X è chiuso - puoi facilmente aggiornarlo al aprilo eseguendo un altro commit.

Tuttavia, quando riapertura un ramo, il "bar" che si vede in Tortoise esisterà ancora nel changeset precedentemente chiuso, e quindi per questo motivo da solo io personalmente optare per una politica di stretta-then-merge. È più istruttivo dal punto di vista visivo, penso, vedere che ti stavi fondendo da qualcosa di cui eri felice (e quindi chiuso il ramo prima dell'unione).

Le cose sono leggermente diverse con le filiali "anonime", in quanto non sono incluse nell'output hg branches quando sono state unite e quindi non richiedono una chiusura esplicita.

Answer 2

Questa non è una questione di gusti e c'è una differenza. In breve, chiudi il ramo, quindi unisci.

Il fatto è che i nomi dei rami Mercurial sono solo "metadati" per ciascun changeset. Influisce sui risultati di determinati comandi come hg branches omette quelli chiusi, oppure hg push non consentire l'aggiunta di una nuova testata per filiale di default. Ma di nuovo - sta filtrando.

Internamente, Mercurial vede il repository come grafico di changeset, DAG specifico. Inoltre, le teste topologiche di tale grafico vengono utilizzate per l'implementazione della logica, ad esempio durante il confronto degli archivi locali e remoti durante lo hg pull. Un numero maggiore di teste topologiche può (leggermente ma ancora) influire sulle prestazioni - How do closed branches affect Mercurial performance?. Inoltre un certo numero di essi può causare 400 Bad Request da Mercurial in esecuzione nel server IIS - https://bitbucket.org/site/master/issue/8263/http-400-bad-request-error-when-pulling.

Quando un primo si unisce e quindi si chiude, il ramo è chiuso, va bene, e l'uomo non vede quel ramo di default. Ma il mercurio ha un'altra testa topologica. Guarda qui sotto per una spiegazione visiva. Quindi chiudere prima.

close then merge    merge then close 
----------------    ---------------- 

@ default, head    @ default, head 
|        | 
o merge    <--> | x close branch, head 
|\        | | 
| x close branch  <--> o | merge 
| |        |\| 
o | dev on default    o | dev on default 
| |        | | 
| o dev on branch    | o dev on branch 
| |        | | 
| o open branch    | o open branch 
|/        |/ 
o default     o default 

Si può guardare here per i dettagli su come siamo arrivati ​​a questa conclusione.

Answer 3

Come la mia azienda ha recentemente scoperto, c'è una buona ragione per preferire l'unione ravvicinata.Come hanno discusso altre risposte, in unire-poi-chiudere si finisce con una "testa topologica" in più, mentre in close-then-merge non si lascia indietro questa testa in più.

Viene visualizzato these extra heads add up e può eventualmente causare problemi nelle operazioni di sincronizzazione (in cui Mercurial deve negoziare quali teste sono su quale lato scoprire i changeset da premere o tirare). Man mano che aumenta il numero di teste topologiche che penzolano, queste operazioni diventano sempre più grandi, fino a quando non diventano they start to fail. Per fortuna, puoi facilmente fare clean them up later ma è probabilmente meglio evitare il problema in primo luogo.