SVN atomic commit how-to

dove mi trovo: riga di comando di LinuxSVN atomic commit how-to

Il problema che ho adesso:

A volte non ho potuto fare commit atomici (costituiti tutte le modifiche necessarie per un particolare biglietto/compito), perché nel repository sono presenti alcuni file, i cui contenuti variano a seconda degli ambienti di sviluppo locali.

Ad esempio: database.xml (nome db, nome utente, password, ecc.). Modifico questo file nel mio ambiente locale, e ogni volta che ho bisogno di effettuare un commit/checkin ho manualmente elencato tutti i file/cartelle richiesti per il commit (escludendo questi file modificati localmente).

Forse si tratta di una decisione di progettazione sbagliata e database.xml deve essere cancellato dal repository e ha cambiato per database.xml.template (memorizzato in SVN), quindi questo file non verrà incluso a commettere fino a quando si esegue manualmente svn add per questo? Forse è un approccio errato - per memorizzare tutte le informazioni dipendenti dall'ambiente nel repository - in questo caso possiamo rompere tutto commettendo una configurazione modificata, ad esempio ..

Come ho capito, la proprietà svn:ignore non ha potuto questa situazione, perché può essere utilizzata solo per i file che non sono memorizzati nel repository ..

Come può essere risolto questo problema?

P.S .: Sto utilizzando Ubuntu e la maggior parte della pura linea di comando per SVN.

fonte

2009-05-03 ep3static

Sono d'accordo con mantenere un file '.template' in Subversion e la configurazione reale, versione modificata, solo localmente.È importante che gli sviluppatori non * * * modifichino il vero file di configurazione per scopi diversi dalla configurazione personale. Cioè, se una nuova opzione deve essere aggiunta al file, allora deve essere aggiunta al file '.template' e quindi ricreare il proprio file di configurazione al di fuori di essa (forse automatizzare la ricostruzione della configurazione da' .template' file con uno script per facilitare il lavoro). –

Sì, avrei database.xml.template in SVN, database.xml.override nei checkout locali e ignorato, e uno script per combinare i due per produrre database.xml. Almeno, lo farei se avessi il tempo di scrivere la sceneggiatura ;-) Altrimenti gli sviluppatori devono fare un'unione manuale in databaes.xml ogni volta che cambia database.xml.template. –

In effetti, se gli sviluppatori vogliono essere davvero fantasiosi, quindi possono fare database.xml.override di un collegamento fisico a un file che controllano la versione nel loro ramo personale del repository, in modo che anche la configurazione personale sia controllata. –

La procedura "standard" per questo è qualcosa di simile (perdona la sintassi SVN, ho usato Bazaar ultimamente):

echo config > database.xml.template 
svn add database.xml.template 
svn ignore database.xml 
svn commit

Poi sulla macchina di sviluppo di ogni persona:

svn checkout 
cp database.xml.template database.xml 
...edit database.xml...

quando commettono,

echo foo > someotherfile 
svn commit

ilIl filenon verrà aggiunto a Subversion.

fonte

2009-05-03 10:26:46 FryGuy

il comando effettivo per rendere svn ignore database.xml sarebbe "svn propset svn: ignore database.xml." (come da svn 1.5.5) – che

Se ricordo correttamente l'uso di propset, sovrascriverò tutti gli altri svn: ignora in posizione. Potresti provare a combinare propget e propset o più facilmente propedit e utilizzare l'editor per aggiungere un'altra riga. –

È necessario memorizzare un modello nel repository, ma non il file effettivo che è necessario modificare localmente.

In questo modo è possibile ricostruire un file pristine, se necessario, senza rischiare di archiviare un file nel repository che non dovrebbe essere presente.

E no, svn: ignorare non ti aiuterà qui.

fonte

2009-05-03 10:22:25

I miei 2 centesimi: prima di tutto è necessario assicurarsi che esista un modo (facile) per armonizzare i percorsi per tutti gli sviluppatori coinvolti nel progetto. Questa può essere la stessa struttura di directory relativa o qualche strato sottile nell'applicazione che supporta alcune shell shell o come $ home,% USERPROFILE% ecc. Sarebbe molto più conveniente nel tempo che lasciare che ogni dev gestisca la propria configurazione non verificata e questo è ciò che gli IDE stanno cercando di fornire.

In generale, i file di configurazione delle versioni sono perfetti per me, è semplicemente il tempo che uno sviluppatore dedica a impostare e non dovrebbe perdersi per caso.

fonte

2014-08-11 08:03:35

SVN atomic commit how-to

risposta

Problemi correlati