Linee guida consigliate per le impostazioni Mercurial

La nozione di un "repository centrale" è l'impostazione abituale per un team di lavorare insieme, come illustra Hginit.com :

Ma con un DVCS, è necessario ricordare che:

• non è necessario un solo repository centrale, è possibile configurare molte versioni replicate di quel reop centrale per scopi diversi (test, pre-distribuzione, ...)
• un unico repository centrale per tutto non funzionerà mai: non puoi mettere tutto in un repository DVCS, perché diventerà troppo pesante per clonare, o conterrà set di file non correlati che ottengono tutti referenziati sotto lo stesso tag, che non sempre hanno senso.
  È necessario rivedere l'organizzazione del set di file che si desidera gestire e conservarli in repository separati.

La cosa meravigliosa di mercurial è che non esiste un modo obbligatorio di fare le cose, puoi fare in modo che il tuo flusso di lavoro segua ciò che è più conveniente per te.

Penso che un sistema minimo sia probabilmente un repository remoto e un repository di sviluppatori clonato da esso. Ma quante distribuzioni hai, quanti sviluppatori hai, quali sono le linee di responsabilità e quanto meglio puoi tenerle nel tuo flusso di lavoro potrebbe essere molto diverso per diversi team e / o progetti, anche all'interno dello stesso dipartimento, per non parlare della compagnia .

Ad esempio, usando l'esempio tratto da hinit che VonC ha pubblicato, se Bob ha trovato un bug nel codice che Rose ha mantenuto, potrebbe hgservire il suo repository, lei potrebbe inserire le sue modifiche, aggiornare il suo suggerimento, rintracciare il problema e spingere la correzione direttamente nel repository di Bobs (senza passare attraverso il server centrale) prima di eseguire l'aggiornamento al proprio ramo di lavoro. Quando Bob è stato contento del loro lavoro (ha confermato che i suoi test di integrazione sono stati eseguiti correttamente), ha potuto inviarlo al repository centrale, dove Joel poteva vedere che era completo.

Se ho capito bene, questo è in realtà più facile che con git dove Bob e Rose dovrebbero collaborare attraverso un repository nudo condiviso. Sospetto che Bob debba clonare il suo repository, lasciare che Rose estrae e spingere indietro verso quel repository, e quindi dovrebbe inserire le sue modifiche, piuttosto semplicemente aggiornando ad un nuovo changeset nel proprio repository.

Successivamente, Joel decide che questa condivisione ad hoc non è appropriata e che tutta la condivisione dovrebbe passare attraverso il repository centrale, ma non vuole che il capo del repository centrale sia mai in uno stato in cui non lo è superare i test di integrazione.

Per risolvere questo problema, Bob ha potuto creare un repository di staging. Qualsiasi repository spinto nell'area di staging avrebbe i test di integrazione eseguiti dal server di integrazione build / continuous e se i test hanno esito positivo, il changeset viene inviato al repository centrale. In caso contrario, il changeset verrà trattenuto fino a quando i test non avranno successo. Se solo il server di integrazione può inviare al repository centrale, Joel ottiene ciò che vuole: Bob e Rose possono collaborare spingendo e spostando l'area di staging, ma il repository centrale avrà sempre una build pulita e testata.

Quindi, in sintesi, il mondo è davvero la tua ostrica.

Gli scenari sopra riportati sono solo due dei numerosi problemi che potresti voler risolvere attraverso il tuo flusso di lavoro. La cosa migliore da fare è chiedere se si dispone di un problema specifico del flusso di lavoro che si desidera risolvere, quindi le persone possono offrire suggerimenti. Fino ad allora, probabilmente vale la pena limitarsi a mantenerlo semplice.

> what is the ideal Mercurial topology ?

Mi piacciono la topologia e il flusso di lavoro descritti in a-successful-git-branching-model .

Nota che il testo parla di git e non di hg / mercurial, ma l'idea alla base è la stessa.

Ciò che conta è il processo mediante il quale ottieni codice da diversi sviluppatori integrati in una macchina in modo che possa essere compilato, testato e impacchettato come release distribuibile.

Ho usato un "agile e unit-test prima di condividere" prima. Hai bisogno di un repository centrale e condiviso per farlo, e la verità è che il processo funziona solo se tutti sanno cosa stanno facendo.

Ho proposto questo schema a un client corrente, e hanno optato per una "integrazione tramite la strategia selettiva di pull / patching . In questo c'è un repository di integrazione centrale, ma è accessibile solo da integratori designati.

Un'altra possibilità è combinare le strategie di cui sopra in un processo a due fasi.

In breve, se si definisce il processo di integrazione che funziona per il proprio team, la topologia del repository richiesta dovrebbe diventare evidente.

In ogni caso, gli sviluppatori si affidano frequentemente ai loro repository locali, in quanto ciò può salvarti da un sacco di dolore quando le build nei repository condivisi / centrali vengono interrotte.