2009-07-25 9 views
5

A volte, quando si lavora con la copia locale, è possibile che le impostazioni di configurazione memorizzate non vengano memorizzate e non è pratico ignorare il file perché contiene anche impostazioni specifiche dell'applicazione.Come si disinfetta la fonte prima di eseguire un commit di subversion?

Ad esempio, un file settings.py di Django contiene sia i dettagli della connessione al database sia le impostazioni del progetto, come ad esempio quali applicazioni caricare.

C'è un modo per disinfettare questi tipi di file quando vengono commessi? E c'è un modo per ripristinare di nuovo le impostazioni locali durante un checkout?

mio ambiente attuale è Linux e la linea di comando di Subversion

risposta

8

Un modo per risolvere questo problema consiste nel mantenere il file di configurazione "standard" in un file diverso, ad esempio settings.py.example. Nella copia di lavoro, copiare settings.py.example in settings.py e lavorare con la copia. Se è necessario apportare una modifica alla configurazione standard, modificare settings.py.example e archiviarlo. In caso contrario, non sarebbe necessario cambiarlo e il settings.py modificato non è nemmeno nel controllo di versione in modo che non venga notato (si può includerlo nella proprietà svn:ignore per renderlo ancora più silenzioso).

+0

Grazie Greg. A volte la soluzione è così ovvia che ti chiedi perché non ci hai pensato tu;) –

2

Io uso ignorare-on-commit elenco modifiche.

Questo sembra essere specifico per TortoiseSVN però. Potrebbe non essere disponibile sulla riga di comando.

2

Ecco come evito questo problema. In genere ho sviluppo, UAT (test di accettazione dell'utente) e configurazioni di produzione. Di solito esistono side-by-side nella stessa directory (o forse separate dev/UAT/directory prod). Questi sono tutti registrati e trattati come codice sorgente. Di conseguenza, le configurazioni del database dev/UAT/prod (ad esempio) possono essere gestite separatamente.

Lo sviluppo avviene indicando le configurazioni di sviluppo (tuttavia si sceglie di farlo). I test automatici scapperà il file di configurazione dev o SVS (a seconda del progetto, ecc)

Inoltre, ho fornire un mezzo per ignorare impostando il mio sistema per controllare la mia home directory prima di caricare questi file di configurazione, e posso fornire sostituzioni che sono veramente personali. Spesso le configurazioni principali specificano solo un sottoinsieme delle variabili, quindi le configurazioni di dev/UAT/prod possono cambiare e crescere, e la mia configurazione personale non ha bisogno di tracciare le modifiche. I miei override personali non sono controllati tramite SVN o simili, poiché è particolare per quello che sto facendo in quel particolare momento.

+0

Non sapevo cosa fosse la UAT. Cercato - è il test di accettazione degli utenti? –

+0

Sì. Quindi il codice migrerebbe da dev/test a UAT alla produzione –

Problemi correlati