Ramificazione fornitore, stile mercuriale?

Question

La scena: Un'applicazione Web acquistata, con aggiornamenti regolari dal fornitore. Quindi, personalizziamo pesantemente l'aspetto e talvolta aggiungiamo le nostre funzionalità o risolviamo un bug prima che il venditore ci arrivi. Per il controllo della versione, abbiamo utilizzato Subversion seguendo il loro modello “Vendor Branch” ogni volta che abbiamo ricevuto una nuova versione. Questo ha l'ulteriore vantaggio di avere una copia vanigliata della versione del loro sistema.

Il problema: Ci piacerebbe passare a Mercurial e probabilmente seguiremo il modello stable/default branching. Mercurial ha perfettamente senso se dovessimo ricevere una sola versione dal nostro fornitore e iniziare a svilupparla da lì. Ma, per qualsiasi motivo, ho difficoltà a capire come gestire le versioni future del venditore.

Il motivo: Qualsiasi aiuto con "ramificazione del fornitore" Lo stile mercuriale sarebbe molto apprezzato.

Answer 1

Utilizzando rami con nome come hai descritto è una buona scelta (anche se not the only choice), ma mi piacerebbe ancora suggerire utilizzando un paio di cloni separate a ben luoghi noti a facilitare questo processo. Fingendo che http://host/hg/ è una hgweb (ex hgwebdir) per la vostra installazione (anche se ssh: // funziona alla grande anche, qualunque cosa), si avrebbe qualcosa di simile:

• http://host/hg/vendor
• http://host/hg/custom

Due repository separati in cui il flusso di dati dal fornitore all'abitudine ma mai l'altra direzione. Il ramo denominato default sarebbe l'unico in vendor e in custom che avresti sia default e .

Quando avete ottenuto un nuovo calo del codice da parte del fornitore che ci si scompattarlo nella directory di lavoro del vendor pronti contro termine, e quindi eseguire:

hg addremove 
hg commit -m 'new drop from vendor, version number x.x.x' 

La vostra storia in quel vendor repo sarà lineare, e non avrà mai nulla che hai scritto.

Ora nel tuo clone locale del custom Repo faresti:

hg update default  # update to the latest head in your default branch 
hg pull http://host/hg/vendor # bring in the new changes from vendor as a new head 
hg merge tip   # merge _your_ most recent default cset with their new drop 

E poi si fa il lavoro di fondere le vostre probabilità di default sui locali con il loro nuovo calo codice. Quando sei soddisfatto dell'operazione di unione (i test superano, ecc.), Dai cloni locali torna al numero http://host/hg/custom.

Questo processo può essere ripetuto, se necessario, fornisce una buona separazione tra la vostra storia e la loro, e permette a tutti la tua squadra non è responsabile per accettare il nuovo codice scende dai fornitori, di occuparsi solo con un normale default/stable configurazione in un unico repo, http://host/hg/custom.

Answer 2

Vorrei utilizzare un ramo del fornitore come ramo aggiuntivo a quelli di default + stabili. Alla fine si sarebbe simile a questa:

V1----V2-------------V3---------V4  Vendor 
\  \    \   \ 
    D1----D2---D3--D4-D5-D6-D7-D8---D9 default 
        \   \ \ 
        S1----------S2---S3 stable