2011-09-28 9 views
5

Aiutami a fare qualche danno! Sono stanco di una mezza dozzina di hit di Google che mi dicono di non farlo mai. Let's Muck cose davvero bene! Sono abbastanza sicuro di poter ottenere i file reali in db/transazioni, quindi come posso rovinarli in modi interessanti? Ho esaminato SVN :: Delta, ma non riesco nemmeno a capire cosa dovrebbe fare (lasciando che qualcuno faccia un bel grafico delle modifiche a un repository? Inviando messaggi in codice alla CIA?).Qual è il formato dei delta in un resversion di subversion e quanto male posso farlo saltare se li cambio in un hook pre-commit?

Davvero non mi interessa sapere più ragioni per non farlo. Lavoro in un ambiente con 40 o 50 altre persone che usano la sovversione. E mentre stiamo codificando, abbiamo bisogno di alcune password nei file web.config, nei file DataSource.groovy, lo nominate. E il solo rifiuto del commit perché li abbiamo lasciati è fastidioso come l'inferno. Dobbiamo salvare i file con le password cancellate manualmente (e dobbiamo aprire quei file, non è come se fossero necessariamente aperti), quindi una volta che abbiamo finito, dobbiamo rimetterli solo per continuare a lavorare? Questa è una buona idea, suppongo che se vuoi solo spaccare le persone ogni volta che commettono fino a quando non sviluppano un riflesso pavloviano per non commettere mai nulla. E perché? Perché i computer non dovrebbero automatizzare le attività? Perché il client software non saprà che il gancio pre-commit non ha effettivamente salvato la versione ancora sul computer dello sviluppatore?

Sono abbastanza agnostico di lingua qui. Mostrami un esempio di come fare ciò che non dovresti fare ... quale file posso modificare da pre-commit? Come interpreto il gobbledygook dopo la riga DELTA # # #? Ci sono delle librerie che ti aiuteranno? Divertiamoci!

PS Seriamente, nessuno ha creato un tag "cattive idee"? WTF.

+2

+1 per deliziosa perversione – daxim

risposta

4

È il processo di compilazione che è difettoso, non Subversion. Se non si devono impegnare password, fare qualcosa del tipo:

I file 1 - Web.config non devono essere impegnati. Invece, commetti i file come Web.config.dev o Web.config.qa.
2 - Avere lo script di build rinominare il file .config appropriato in Web.config e quindi sostituire il token in modo che vengano inserite le password appropriate. Queste informazioni possono provenire da un altro file che non è nemmeno impegnato che dice in quale ambiente ci si trova (quindi sa quale file .config utilizzare) e quali sono le password.

+0

Questo è davvero bello ... dicendomi che non dovremmo fare il controllo di versione sui file. Immagino che se uno è perso o corrotto in produzione (successo solo un mese fa), allora possiamo chiedere loro di tirare i backup su nastro e farlo funzionare di nuovo in un paio di giorni. I suoni sul lato client sono davvero belli, ci sono solo diverse decine di sviluppatori ... e quando i nuovi computer verranno implementati in un paio di mesi, possiamo installarlo nuovamente su decine di sistemi solo per divertimento! –

+2

@ John Non penso che tu mi stia seguendo. I file che non si impegnano vengono generati automaticamente dallo script di build. L'unico file che non viene creato dal checkout o dallo script di build è il file della password, che non è esplicitamente impegnato come requisito da parte tua. Analogamente, lo script di distribuzione crea il web.config per te. – RedFilter

+2

@JohnO: No, ti sta dicendo di controllare la versione dei file, tranne che senza le password inserite, e quindi avere un processo automatico per inserire la password. Un po 'come il modo in cui la versione controlla un file '.c', ma non il' .o' generato. – derobert

Problemi correlati