MQ vs. filiali in Mercurial

Question

Lavoro con Mercurial da un po 'di tempo. Quando si apportano modifiche (private) a software di terze parti, in passato ho sempre creato un ramo denominato separato per queste modifiche. Quando il codice a monte si aggiorna, semplicemente lo unisco al mio ramo nominato.

Oggi ho letto su MQ (Mercurial Queues - capitoli 12 e 13). Penso di aver capito il concetto alla base di MQ, quindi la mia domanda è:

C'è qualche vantaggio di MQ su (denominato) rami in Mercurial (per il mio scenario)?

Answer 1

Il vantaggio principale di MQ su rami con nome sono:

• È possibile rivedere le patch. Ciò consente di modificare la cronologia e di mantenere una serie di patch pulite e logiche sulla parte superiore del codice upstream: se si nota un errore in una patch, si aggiorna la patch anziché effettuare una nuova commit.

• Le modifiche alle patch saranno nettamente separate dalle modifiche apportate a monte. Quando unisci due rami, mescoli i due flussi di sviluppo. Ciò rende difficile vedere le modifiche che hai apportato senza vedere anche le modifiche provenienti dal ramo upstream.

• I nomi delle patch sono temporanei. Quando si applica una patch applicata a hg qfinish, non vi è traccia del nome del patch rimasto nel commit. Quindi puoi usare MQ senza coordinare prima con il repository upstream poiché non noteranno mai MQ.

• Si evita l'unione. Invece di fondersi con l'ultimo codice da upstream, è rebase le patch applicate. Questo ti dà una storia più semplice. La cronologia è ovviamente falsa poiché fingi di aver creato tutte le tue patch dopo il vedendo il codice da monte - quando infatti lo hai fatto in parallelo con upstream e successivo spostato le tue patch alla punta di upstream.

• Non si dispone di un nome di diramazione permanente nei changeset. Le persone a volte sono treat named branches as disposable e si arrabbiano quando si rendono conto che un ramo con nome è stato corretto nella cronologia. (Si può effettivamente impostare il nome del ramo con hg branch prima di spingere le patch in modo da questo punto non è poi così male.)

Svantaggi di MQ sono:

• Si tratta di uno strumento in più per imparare.È potente, ma ti dà anche più possibilità di spararti ai piedi. L'esecuzione di hg qdelete in realtà sostituirà la patch e potrai quindi eliminare i dati. (Penso che questo vada bene, ma abbiamo avuto un utente Git che si è rivolto alla nostra mailinglist lamentandosi di questo.)

• È molto più difficile collaborare con gli altri. È possibile possibile trasformare .hg/patches in un repository e spingere/tirare le patch tra repository ma è difficile farlo se si è più di un singolo sviluppatore. Il problema è che finisci per unire le patch se più di una persona aggiorna la stessa patch.

• Non si dispone di un nome di diramazione permanente nei changeset. Se usi correttamente le branch nominate e usi nomi di diramazioni stabili ea lungo termine, ti mancherà questo quando utilizzi MQ.

Answer 2

Buona domanda. Dipende. Personalmente non mi piace il sistema di ramificazione mercuriale, e cerco di evitarlo quando posso (usando i segnalibri spinti al posto del ramo).

MQ è un ottimo strumento, con grande potenza e grandi insidie. Puoi anche considerare l'utilizzo di pbranch.

MQ è un ottimo strumento se è necessario produrre e mantenere un set di patch per un progetto, ad esempio aggiungere feature-x a un progetto e mantenere aggiornate le patch con il codice upstream.

I segnalibri (o rami se si desidera) sono adatti per attività di sviluppo breve che richiedono l'unione nel codice upstream.