È possibile? Se sì, come faccio a fare questo?Formattazione automatica del codice SVN al check-in?
Il codice è in C# e stiamo utilizzando TortoiseSVN.
Voglio semplicemente formattare automaticamente il codice ad ogni controllo.
Grazie mille
Stai toccando il terreno della guerra santa. Mussing con la formattazione della gente sta chiedendo forconi e torce.
La mia raccomandazione: Non.
per non parlare, se stai parlando C#, e gli sviluppatori stanno utilizzando Visual Studio, VS ha un sacco di strumenti di auto-formattazione. Semplicemente inserendo la parentesi graffa chiusa e VS può/si formatterà automaticamente il tuo codice.
Una soluzione migliore potrebbe essere quella di ottenere tutti i vostri sviluppatori di utilizzare le stesse impostazioni di formattazione automatica.
Strumenti -> Opzioni, Editor di testo -> C# -> Formattazione
Queste impostazioni sono esportabili, quindi se è possibile ottenere il team ad accettare di utilizzare le stesse impostazioni di code-formattazione in VS, puoi evitare il problema di eseguirlo nel tuo sistema di controllo del codice sorgente, che è meglio lasciare a fare ciò che sa fare meglio.
Se sei decisa a fare questo, un pre-commit hook, come altri hanno detto, è la strada da percorrere. Se il server SVN è in esecuzione su Windows, potrei raccomandare lo CaptainHook per scrivere gli script di hook? Hookscripts plug-in che puoi scrivere in qualsiasi linguaggio .NET.
penso che si può fare questo usando a pre-commit hook nel repository.
Modifica Per le persone che pensano che questa sia una cattiva idea (non sto dicendo che non lo sia): non è raro che le organizzazioni applichino uno stile di codice o una formattazione di codice specifici. A volte queste regole possono essere abbastanza pedante e rigorosamente applicate, e anche se di solito sono le azioni umane coinvolte in questo (vale a dire la formattazione dello stile corretto prima di inviare qualsiasi cosa al repository), l'automazione del processo a volte può essere utile.
Un approccio alternativo potrebbe essere quello di fare la verifica automaticamente prima del commit, ma ancora consentire il commit, anche se il controllo ha esito negativo, ma poi solo inviare una e-mail o qualche altra notifica per indicare che qualcuno non ha seguito la stile.
È possibile, ma anche una pessima idea.
Nessun formattatori codice automatici sono perfetti, e posso quasi garantire che sarà spuntare la gente fuori.
Detto questo, se si vuole farlo, considerare di usare pre-commit ganci.
Il server SVN è in esecuzione su un sistema Windows o Linux? E quale programma di formattazione vuoi usare?
Sto guardando NArrange (http://www.narrange.net) – SuperSuperDev1234
Sì, non mi sembra neanche una buona idea. Una certa disciplina da parte dei programmatori è MOLTO più sicura del codice rotto. – crashmstr
In tal caso non posso fare molto ... Non so molto di Subversion su Windows ... Ma sembra che @Yoopergeek ci abbia coperto. Ad ogni modo, una cosa che dovresti considerare è, invece di aggiungere un hook, scrivere uno script in modo che gli sviluppatori possano facilmente formattare il loro codice. Quindi, se è presente un brutto codice, puoi chiedere gentilmente di usare lo strumento. –
Con uno script di hook pre-commit, è possibile farlo, sì. Ma sono sicuro che rimuoverete quello script dopo il primo commit perché avrete grossi problemi.
Se si modificano i dati che vengono commessi, il client non lo sa. Quindi, dopo un tale commit in cui il tuo script 'corregge' la formattazione di un file, il contenuto del file nel repository è diverso rispetto ai file nella tua copia di lavoro. Ma la tua copia di lavoro pensa ancora che sia aggiornata con il repository (dopotutto, le modifiche sono appena state commesse).
Così il prossimo aggiornamento, si otterrà in un inferno - copia di lavoro spezzato, gli utenti arrabbiati, ...
E, naturalmente, si potrebbe rompere la build - formattazione auto ha in tal senso a volte.
Si può ovviamente implementare uno script di hook che controlla per una formattazione corretta e restituisce un errore in caso contrario, è perfettamente soddisfacente.
E poiché si utilizza TortoiseSVN, è possibile provare a eseguire la formattazione in uno .
Questa è la migliore ragione per ** non ** per fare ciò: repo <-> incoerenza di copia di lavoro. Ottimo punto. – Yoopergeek
Il problema della copia di lavoro in conflitto/non aggiornato non è diverso dal fatto che chiunque altro abbia eseguito il commit di una nuova versione di un file nel repository. Questo verrà risolto scaricando l'ultima versione dal server e, se l'utente dimenticherà, il client svn lo rileverà quando tenterà di eseguire nuovamente il commit del file. –
Penso che il problema, come Stefan sta affermando, è che, commettendo, stai costringendo il commiter a dover aggiornare immediatamente dopo il commit perché il hook pre-commit avrà cambiato il loro codice. – Yoopergeek
come la maggior parte delle persone qui sono d'accordo aggiungendo un pre-commit-hook che riscrive il loro codice è sbagliato, tuttavia è possibile avere un hook pre-commit che rifiuta il codice che non è formattato per le pratiche di codifica e informa l'utente di tale errore.
Lo consiglio vivamente.
Utilizzare uno script di pre-commit o, meglio ancora, trovare un modo per farlo automaticamente nell'IDE (il pre-commit sposterà il file modificato sul client). Eclipse può auto formattare al salvataggio.
La logica di questo è che se gli sviluppatori si formattano in modo diverso, troverai i file su cui è stato eseguito il commit in cui il commit è solo una modifica della formattazione e causerà confusione infinita.
Un modello di formattazione comune è un'ottima idea. Sarà difficile da presentare, ma ne varrà la pena. Tutte le modifiche saranno modifiche reali e non solo modifiche di formattazione. Nella mia esperienza gli sviluppatori vedranno i benefici e lo accetteranno.
Ho lavorato con cvs e java e ho usato jalopy in formato auto. Stavamo usando un sistema di ramificazione quindi era obbligatorio e funzionava molto bene.
Completamente d'accordo: controlla le opzioni di formattazione del codice nel repository, quindi tutti possono condividerle. –
Woah. Fino a quando non l'hai appena detto, non mi era venuto in mente di includere le impostazioni di formattazione VS esportate con il progetto nel controllo del codice sorgente. Questa è una buona idea. – Yoopergeek
Per CaptainHook, prendi anche il file patch per correggere un paio di bug –