Mercuriale: mantenere 2 rami sincronizzati ma con alcune differenze persistenti?

Question

Sono uno sviluppatore web che lavora da solo con django e sto cercando di capire come utilizzare i siti con Mercurial. Quello che mi piacerebbe avere è essere in grado di mantenere un repository che posso usare sia per la produzione che per lo sviluppo. Ci saranno sempre alcune differenze tra produzione/sviluppo (ad esempio potrebbero utilizzare database diversi, lo sviluppo avrà sempre il debug attivato) ma nel complesso saranno sincronizzati. Mi piacerebbe anche essere in grado di apportare modifiche direttamente sul server di produzione (riordinando html o css, semplici correzioni di bug, ecc.).

Il flusso di lavoro che intendo utilizzare per fare questo è la seguente:

• creare 2 rami, prod e dev (Tutte le impostazioni inizialmente impostati su impostazioni di produzione)
• Change settings.py e pochi altre cose nel ramo dev. Quindi ora ho 2 teste, e da ora in poi il repository avrà sempre 2 teste.
• (Sulla macchina di sviluppo) Apportare le modifiche a dev, quindi utilizzare 'hg trapianto' per copiare i changeset rilevanti in produzione.
• spinta da padroneggiare repository
• (Sul server di produzione) Tirare da maestro di pronti contro termine, l'aggiornamento a testa prod

Nota: è anche possibile apportare modifiche direttamente al prod fino a quando si trapiantare le modifiche nel dev.

Questo flusso di lavoro ha lo svantaggio che ogni volta che si apporta una modifica, non solo si deve eseguire il commit su qualsiasi ramo su cui si effettua la modifica, ma è necessario trapiantarlo sull'altro ramo. C'è un modo più ragionevole di fare ciò che voglio qui, magari usando le patch? Oppure, in caso contrario, esiste un modo per automatizzare il processo di commit per il trap automatico del changeset sull'altro ramo e sarebbe una buona idea?

Answer 1

Probabilmente userò Mercurial Queues per qualcosa di simile. Conservare il repository principale come versione di sviluppo e disporre di una patch for-production che apporta le modifiche necessarie per la produzione.

Answer 2

Forse provare qualcosa di simile: (Stavo proprio pensando a questo problema, nel mio caso si tratta di un database SQLite)

• Aggiungi settings.py a .hgignore, per tenerlo fuori dal repository.
• prendere il vostro file settings.py dai due rami separati e spostarli in due file separati, settings-prod.py e settings-dev.py
• creare uno script deploy che copia il file delle impostazioni-X opportuno settings.py, in modo da poter distribuire in entrambi i casi.

Se si dispone di un paio di file aggiuntivi, fare la stessa cosa per loro. Se disponi di molti file ma sono tutti nella stessa directory da soli, puoi semplicemente creare una coppia di directory: production e development, quindi copiare o collegare simbolicamente il file appropriato in una directory deploy.

Se avete fatto qualcosa del genere, potreste fare a meno della necessità di ramificare il vostro repository.

Answer 3

seguito sono due possibili soluzioni utilizzando uno mercuriali e non utilizzando mercuriale:

1. utilizzare il nome host per passare da prod e svi. Abbiamo un singolo controllo nella parte superiore del nostro file delle impostazioni che esamina la variabile di ambiente SERVER_NAME. Se si tratta di www.production.com è il DB prod e in caso contrario preleva un DB dev/test/stage predefinito o specificato.
2. Utilizzando Mercurial, è sufficiente disporre di un clone che è dev e di un clone che è pungolo, apportare tutte le modifiche in dev e in fase di distribuzione passare da dev a prod. Dopo aver tirato, avrai 2 teste in coda divergenti da un singolo antenato comune (l'ultimo schieramento). Una testa avrà un singolo changeset che contiene solo le differenze tra le distribuzioni di dev e prod, e l'altra avrà tutto il nuovo lavoro. Uniscili nel prod clone, selezionando le modifiche ai prodotti in conflitto, ovviamente, e disponi di un'installazione distribuibile e sei pronto a fare più lavoro su "dev". Non c'è bisogno di ramificarsi, trapiantare o usare le code. Finché non si estrae mai quel changeset con le impostazioni prod in "dev", sarà sempre necessaria un'unione dopo aver estratto da dev, e se sono solo poche righe non c'è molto da fare.

Answer 4

Effettivamente lo faccio utilizzando rami nominati e fusione diretta anziché trapianto (che è più affidabile, IMO). Questo di solito funziona, anche se a volte (quando hai modificato i diversi file sull'altro ramo), dovrai prestare attenzione a non rimuovere di nuovo le differenze quando ti unisci.

Quindi funziona benissimo se non si cambiano molto i diversi file.

Answer 5

Ho risolto questo con le impostazioni locali.

1. Aggiungi per settings.py:

    
   try: 
   from local_settings import * 
   except ImportError: 
   pass 
   

2. touch local_settings.py

3. Aggiungi ^local_settings.py$ al .hgignore

Ogni implementare lo faccio ha il proprio le impostazioni locali (roba DB genere diverso e indirizzi email di origine diversa).

PS: leggere solo le "versioni minificate di porzione javascript" in seguito. Per questo, suggerirei un hook post-update e un'impostazione di configurazione (come JS_EXTENSION).

Esempio (dalla parte superiore della mia testa non testato, adattare, se necessario!):

1. Mettere JS_EXTENSION =' .raw.js' nel file settings.py;
2. Put JS_EXTENSION = '.mini.js 'nel tuo file local_settings.py sul server di produzione;
3. Variazione JS inclusione da:

   <script type="text/javascript" src="blabla.js"></script>

   A:

   <script type="text/javascript" src="blabla{{JS_EXTENSION}}"></script>

4. Fai un gancio post-aggiornamento che cerca *.raw.js e genera .mini.js (versioni minified di materie prime);
5. Aggiungi .mini.js$ al .hgignore