Devo memorizzare il codice generato nel controllo del codice sorgente

Questo è un dibattito a cui prendo parte. Vorrei avere più opinioni e punti di vista.

Abbiamo alcune classi che vengono generate in fase di compilazione per gestire le operazioni DB (in questo caso specifico, con SubSonic, ma non credo sia molto importante per la domanda). La generazione è impostata come passaggio di pre-compilazione in Visual Studio. Quindi ogni volta che uno sviluppatore (o il processo di compilazione ufficiale) esegue una compilazione, queste classi vengono generate e quindi compilate nel progetto.

Ora alcune persone affermano che avere queste classi salvate nel controllo del codice potrebbe causare confusione, nel caso in cui il codice ottenuto non corrisponda a quello che sarebbe stato generato nel proprio ambiente.

Vorrei avere un modo per risalire alla storia del codice, anche se di solito viene trattato come una scatola nera.

Eventuali argomenti o controargomentazioni?

Non selezionerò una risposta accettata a questo punto per i motivi sopra menzionati.

Salvarlo nel controllo del codice sorgente è più un problema di quanto valga la pena.

Devi fare un commit ogni volta che fai una build affinché abbia un valore.

Generalmente lasciamo il codice generato (idl, roba jaxb, ecc.) Fuori dal controllo del codice sorgente in cui lavoro e non è mai stato un problema

Mettilo nel controllo del codice sorgente. Il vantaggio di avere la cronologia di tutto ciò che scrivi disponibile per i futuri sviluppatori supera il piccolo dolore di ricostruire occasionalmente dopo una sincronizzazione.

Ogni volta che voglio mostrare le modifiche a un albero dei sorgenti sul mio repository personale, tutti i "file generati" verranno visualizzati come modificati e necessitano di essere trasferiti.

Preferirei avere un elenco più pulito di modifiche che includano solo gli aggiornamenti reali che sono stati eseguiti e non le modifiche generate automaticamente.

Lasciali fuori e poi, dopo una compilazione, aggiungi un "ignora" su ciascuno dei file generati.

Guardala in questo modo: controlli i tuoi file oggetto nel controllo del codice sorgente? I file sorgente generati sono artefatti di build proprio come i file oggetto, le librerie e gli eseguibili. Dovrebbero essere trattati allo stesso modo. La maggior parte sosterrebbe che non dovresti controllare i file oggetto generati e gli eseguibili nel controllo del codice sorgente. Gli stessi argomenti si applicano alla sorgente generata.

Se hai bisogno di guardare la versione storica di un file generato, puoi sincronizzarlo con la versione storica dei suoi sorgenti e ricostruirlo.

Il controllo dei file generati di qualsiasi tipo nel controllo del codice sorgente è analogo alla denormalizzazione del database. Ci sono a volte ragioni per fare questo (in genere per le prestazioni), ma questo dovrebbe essere fatto solo con grande cura in quanto diventa molto più difficile da mantenere la correttezza e coerenza, una volta che i dati sono denormalizzato.

Direi che dovresti evitare di aggiungere qualsiasi codice generato (o altri artefatti) al controllo del codice sorgente. Se il codice generato è lo stesso per l'input fornito, puoi semplicemente controllare le versioni che desideri diff e generare il codice per il confronto.

Io chiamo il principio DRY. Se nel repository sono già presenti i "file sorgente" che vengono utilizzati per generare questi file di codice in fase di compilazione, non è necessario eseguire il commit dello stesso codice "due volte".

Inoltre, potresti evitare alcuni problemi in questo modo se, ad esempio, la generazione del codice si interrompe un giorno.

No, per tre ragioni.

1. Il codice sorgente è tutto ciò che è necessario e sufficiente per riprodurre un'istantanea della tua applicazione in un momento attuale o precedente - niente di più e niente di meno. Parte di ciò che ciò implica è che qualcuno è responsabile di tutto ciò che è stato registrato. In genere sono felice di essere responsabile del codice che scrivo, ma non del codice generato come conseguenza di ciò che scrivo.

2. Non voglio che qualcuno sia tentato di provare a collegare una build da fonti primarie utilizzando codice intermedio che può o non può essere attuale (e, cosa più importante, di cui non voglio assumermi la responsabilità). allettante per alcune persone di farsi coinvolgere in un processo insignificante di debug dei conflitti nel codice intermedio basato su build parziali.

3. Una volta che è nel controllo del codice sorgente, accetto la responsabilità di un file. essendo lì, b. essendo attuale, e c. essendo integrabile in modo affidabile con tutto il resto. Ciò include rimuoverlo quando non lo uso più. Meno responsabilità è, meglio è.

Non credo proprio che dovresti registrarli.

Sicuramente qualsiasi cambiamento nel codice generato sarà rumore - cambiamenti tra ambienti, o cambiamenti come risultato di qualcos'altro - ad esempio un cambiamento nel tuo DB. Se gli script di creazione del tuo DB (o qualsiasi altra dipendenza) sono nel controllo del codice sorgente, allora perché hai bisogno anche degli script generati?

La regola generale è no , ma se ci vuole tempo per generare il codice (a causa dell'accesso al DB, dei servizi web, ecc.), Allora potresti voler salvare una versione memorizzata nella cache nel controllo del codice sorgente e salvare tutti il ​​dolore.

Anche gli strumenti devono essere consapevoli di questo e gestire il check-out dal controllo del codice sorgente quando necessario, troppi strumenti decidono di eseguire il check-out dal controllo del codice sorgente senza alcun motivo.
Un buon strumento utilizzerà la versione cache senza toccarla (né modificare i passaggi temporali sul file).

Inoltre è necessario inserire un grande avviso all'interno del codice generato affinché le persone non modifichino il file, un avviso in alto non è sufficiente, devi ripeterlo ogni dozzina di righe.

Non memorizziamo nemmeno il codice DB generato: poiché viene generato, puoi ottenerlo a piacimento in qualsiasi versione data dai file sorgente. Memorizzarlo sarebbe come memorizzare bytecode o simili.

Ora devi assicurarti che il generatore di codice utilizzato in una determinata versione sia disponibile! Le versioni più recenti possono generare codice diverso ...

Lascialo fuori.

Se stai registrando i file generati stai facendo qualcosa di sbagliato. Ciò che non va potrebbe essere diverso, potrebbe essere che il tuo processo di costruzione sia inefficiente o qualcos'altro, ma non vedo che sia mai una buona idea. La cronologia dovrebbe essere associata ai file di origine, non a quelli generati.

Crea solo un mal di testa per le persone che poi finiscono per provare a risolvere le differenze, trovare i file che non sono più generati dalla build e quindi eliminarli, ecc.

Un mondo di dolore attende coloro che archiviano i file generati!

Esiste un caso speciale in cui si desidera archiviare i file generati: quando potrebbe essere necessario compilare su sistemi in cui gli strumenti utilizzati per generare gli altri file non sono disponibili. Il classico esempio di questo, e uno con cui lavoro, è il codice Lex e Yacc. Poiché sviluppiamo un sistema runtime che deve essere compilato ed eseguito su un'enorme varietà di piattaforme e architetture, possiamo fare affidamento solo sui sistemi di destinazione per avere compilatori C e C ++, non gli strumenti necessari per generare il codice di lexing / parsing per la nostra definizione di interfaccia traduttore. Quindi, quando cambiamo le nostre grammatiche, controlliamo il codice generato per analizzarlo.

arrivando un po 'in ritardo ... comunque ...

Metteresti il ​​file intermedio del compilatore nel controllo della versione del codice sorgente? In caso di generazione di codice, per definizione il codice sorgente è l'input del generatore mentre il codice generato può essere considerato come file intermedi tra la sorgente "reale" e l'applicazione costruita.

Quindi direi: non mettere il codice generato sotto il controllo della versione, ma il generatore e il suo input.

In concreto, lavoro con un generatore di codice che ho scritto: non ho mai dovuto mantenere il codice sorgente generato sotto il controllo della versione. Direi anche che poiché il generatore ha raggiunto un certo livello di maturità, non ho dovuto osservare il contenuto del codice generato sebbene l'input (ad esempio la descrizione del modello) sia cambiato.

In alcuni progetti aggiungo il codice generato al controllo del codice sorgente, ma dipende davvero. La mia linea guida di base è che se il codice generato è una parte intrinseca del compilatore, non lo aggiungerò. Se il codice generato proviene da uno strumento esterno, come SubSonic in questo caso, aggiungerei if al controllo del codice sorgente. Se aggiorni periodicamente il componente, voglio conoscere le modifiche nella sorgente generata in caso di bug o problemi.

Per quanto riguarda il codice generato che deve essere archiviato, uno scenario peggiore è la differenziazione manuale dei file e il ripristino dei file se necessario. Se stai usando svn, puoi aggiungere un hook pre-commit in svn per negare un commit se il file non è realmente cambiato.

Il compito della gestione della configurazione (di cui il controllo della versione è solo una parte) è quello di poter fare quanto segue:

• Scopri quali modifiche e correzioni di bug sono state apportate a ogni build fornita.
• Essere in grado di riprodurre esattamente qualsiasi build fornita, a partire dal codice sorgente originale. Il codice generato automaticamente non conta come "codice sorgente" indipendentemente dalla lingua.

Il primo assicura che quando dici al cliente o all'utente finale "il bug che hai segnalato la scorsa settimana è stato risolto e la nuova funzionalità è stata aggiunta" non tornano due ore dopo e dicono "no, non è stato". Inoltre si assicura che non dicano "Perché sta facendo X? Non abbiamo mai chiesto X".

Il secondo significa che quando il client o l'utente finale segnala un bug in una versione che hai rilasciato un anno fa puoi tornare a quella versione, riprodurre il bug, risolverlo e dimostrare che è stata la tua correzione ha eliminato il bug anziché qualche perturbazione del compilatore e altre correzioni.

Ciò significa che anche il compilatore, le librerie, ecc. Devono far parte di CM.

Quindi ora per rispondere alla tua domanda: se puoi fare tutto quanto sopra, non è necessario registrare alcuna rappresentazione intermedia, perché hai comunque la garanzia di ottenere la stessa risposta. Se non puoi fare tutto quanto sopra, tutte le scommesse sono annullate perché non puoi mai garantire di fare la stessa cosa due volte e ottenere la stessa risposta. Quindi potresti anche mettere tutti i tuoi file .o sotto il controllo della versione.

Dipende davvero. In definitiva, l'obiettivo è essere in grado di riprodurre ciò che avevi, se necessario. Se sei in grado di rigenerare esattamente i tuoi binari, non è necessario salvarli. ma devi ricordare che per ricreare le tue cose probabilmente avrai bisogno della tua configurazione esatta con cui l'hai fatto in primo luogo, e questo non significa solo il tuo codice sorgente, ma anche il tuo ambiente di compilazione, il tuo IDE, forse anche altre librerie , generatori o roba, nella configurazione esatta (versioni) che hai usato.

Ho avuto problemi nei progetti in cui abbiamo aggiornato il nostro ambiente di compilazione a versioni più recenti o persino a quelle di altri fornitori, dove non siamo stati in grado di ricreare gli esatti binari che avevamo prima. Questo è un vero problema quando i binari da distribuire dipendono da una sorta di hash, specialmente in un ambiente protetto, ei file ricreati in qualche modo differiscono a causa degli aggiornamenti del compilatore o altro.

Quindi, memorizzare il codice generato: direi di no. I binari oi risultati finali rilasciati, inclusi gli strumenti con cui li hai riprodotti, li archiverei. E poi, non è necessario archiviarli nel controllo del codice sorgente, basta fare un buon backup di quei file.

La risposta corretta è "Dipende". Dipende da quali sono le esigenze del cliente. Se puoi ripristinare il codice a una particolare versione e resistere a qualsiasi controllo esterno senza di esso, allora non sei ancora su un terreno solido. Come sviluppatori dobbiamo considerare non solo il "rumore", il dolore e lo spazio su disco, ma il fatto che abbiamo il compito di generare proprietà intellettuale e che potrebbero esserci ramificazioni legali. Saresti in grado di dimostrare a un giudice che sei in grado di rigenerare un sito web esattamente come lo vedeva un cliente due anni fa?

Non sto suggerendo di salvare o non salvare i file generati, in qualunque modo decidi se non stai coinvolgendo gli esperti in materia della decisione che probabilmente stai sbagliando.

I miei due centesimi.

Ci sono buoni argomenti sia a favore che contro presentati qui. Per la cronaca, creo il sistema di generazione T4 in Visual Studio e la nostra opzione predefinita out-of-the-box fa sì che il codice generato venga archiviato. Devi lavorare un po 'di più se preferisci non fare il check-in.

Per me la considerazione chiave è variare l'output generato quando l'input o il generatore stesso vengono aggiornati.

Se non hai il tuo output controllato, devi prendere una copia di tutto il codice generato prima di aggiornare un generatore o modificare l'input per poterlo confrontare con l'output della nuova versione. Penso che questo sia un processo abbastanza noioso, ma con l'output controllato, è semplice differenziare il nuovo output dal repository.

A questo punto, è ragionevole chiedersi "Perché ti interessano i cambiamenti nel codice generato?" (Soprattutto rispetto al codice oggetto.) Credo che ci siano alcuni motivi chiave, che si riducono allo stato dell'arte attuale piuttosto che a qualsiasi problema intrinseco.

1. Crei codice scritto a mano che si integra perfettamente con il codice generato. Questo non è il caso nel complesso con i file obj di questi tempi. Quando il codice generato cambia, è purtroppo abbastanza spesso il caso che del codice scritto a mano debba essere modificato per corrispondere. La gente spesso non osserva un alto grado di retrocompatibilità con i punti di estensibilità nel codice generato.

2. Il codice generato cambia semplicemente il suo comportamento. Non lo tollereresti da un compilatore, ma in tutta onestà, un generatore di codice a livello di applicazione si rivolge a un diverso campo di problemi con una gamma più ampia di soluzioni accettabili. È importante vedere se le supposizioni che hai fatto sul comportamento precedente sono ora infrante.

3. Semplicemente non ti fidi al 100% dell'output del tuo generatore dal rilascio al rilascio. C'è molto valore da ottenere dagli strumenti del generatore anche se non sono costruiti e mantenuti con il rigore del fornitore del compilatore. La versione 1.0 potrebbe essere stata perfettamente stabile per la tua applicazione, ma forse la 1.1 ha alcuni problemi per il tuo caso d'uso ora. In alternativa, modifichi i valori di input e scopri che stai esercitando un nuovo pezzo del generatore che non avevi usato prima - potenzialmente rimarrai sorpreso dai risultati.

Essenzialmente tutte queste cose si riducono alla maturità degli strumenti: la maggior parte dei generatori di codice per app aziendali non è vicina al livello che i compilatori o persino gli strumenti a livello di lex / yacc sono stati per anni.

Entrambe le parti hanno argomenti validi e ragionevoli ed è difficile essere d'accordo su qualcosa di comune. I sistemi di controllo della versione (VCS) tengono traccia dei file che gli sviluppatori vi inseriscono e presumono che i file all'interno di VCS siano realizzati a mano dagli sviluppatori e che gli sviluppatori siano interessati alla cronologia e al cambiamento tra le revisioni dei file. Questa ipotesi equipara i due concetti, "Voglio ottenere questo file quando eseguo il checkout". e "Sono interessato alla modifica di questo file".

Ora, gli argomenti di entrambe le parti potrebbero essere riformulati in questo modo:

• "Voglio ottenere tutti questi file generati quando eseguo il checkout, perché non ho lo strumento per generarli in questa macchina."
• "Non dovrei metterli in VCS, poiché non sono interessato alla modifica di questo file."

Fortunatamente, sembra che i due requisiti non siano fondamentalmente in conflitto. Con qualche estensione degli attuali VCS, dovrebbe essere possibile avere entrambi. In altre parole, è un falso dilemma. Se riflettiamo un po ', non è difficile rendersi conto che il problema deriva dal presupposto che le VCS hanno. I VCS dovrebbero distinguere i file, che sono realizzati a mano dagli sviluppatori, dai file che non sono realizzati a mano dagli sviluppatori, ma che si trovano all'interno di questo VCS. Per la prima categoria di file, che di solito chiamiamo file sorgente (codice), i VCS hanno fatto un ottimo lavoro ora. Per quest'ultima categoria, i VCS non hanno ancora avuto tale concetto, per quanto ne so.

Sommario

Prenderò git come esempio per illustrare cosa intendo.

• git status non dovrebbe mostrare i file generati per impostazione predefinita.
• git commit dovrebbe includere i file generati come istantanea.
• git diff non dovrebbe mostrare i file generati per impostazione predefinita.

PS

Gli hook Git potrebbero essere usati come soluzione alternativa, ma sarebbe fantastico se git lo supportasse in modo nativo. gitignorenon soddisfa i nostri requisiti, poiché i file ignorati non verranno inseriti nei VCS.enter code here

Direi per. Se stai utilizzando un processo di integrazione continua che verifica il codice, modifica il numero di build, crea il software e quindi lo verifica, è più semplice e facile avere quel codice come parte del tuo repository.

Inoltre, è parte integrante di ogni "istantanea" che fai del tuo repository software. Se fa parte del software, dovrebbe far parte del repository.

Direi che sì, vuoi metterlo sotto il controllo del codice sorgente. Dal punto di vista della gestione della configurazione TUTTO ciò che viene utilizzato per produrre una build software deve essere controllato in modo che possa essere ricreato. Capisco che il codice generato possa essere facilmente ricreato, ma si può argomentare che non è lo stesso poiché la data / timestamp sarà diversa tra le due build. In alcune aree come il governo, richiedono molte volte questo è ciò che viene fatto.

In generale, il codice generato non deve essere memorizzato nel controllo del codice sorgente perché la cronologia delle revisioni di questo codice può essere tracciata dalla cronologia delle revisioni del codice che lo ha generato!

Tuttavia, sembra che l'OP stia utilizzando il codice generato come livello di accesso ai dati dell'applicazione invece di scriverne uno manualmente. In questo caso, cambierei il processo di compilazione e invierei il codice al controllo del codice sorgente perché è un componente critico del codice di runtime. Ciò rimuove anche la dipendenza dallo strumento di generazione del codice dal processo di compilazione nel caso in cui gli sviluppatori debbano utilizzare versioni diverse dello strumento per rami diversi.

Sembra che il codice debba essere generato solo una volta invece di ogni build. Quando uno sviluppatore deve aggiungere / rimuovere / modificare il modo in cui un oggetto accede al database, il codice dovrebbe essere generato di nuovo, proprio come fare modifiche manuali. Ciò accelera il processo di creazione, consente di effettuare ottimizzazioni manuali al livello di accesso ai dati e la cronologia del livello di accesso ai dati viene conservata in modo semplice.

(Purtroppo) finisco per mettere molte fonti derivate sotto il controllo del codice sorgente perché lavoro a distanza con persone che non possono essere disturbate a creare un ambiente di costruzione appropriato o che non hanno le capacità per configurarlo in modo che il le fonti derivate sono costruite esattamente nel modo giusto. (E quando si tratta di Gnu autotools, io stesso sono una di quelle persone! Non posso lavorare con tre diversi sistemi, ognuno dei quali funziona con una diversa versione di autotools, e solo quella versione.)

Questo tipo di difficoltà si applica probabilmente più a progetti part-time, di volontariato e open-source che a progetti a pagamento in cui la persona che paga le bollette può insistere per un ambiente di costruzione uniforme.

Quando si esegue questa operazione, in pratica ci si impegna a creare i file derivati ​​solo in un sito o solo in siti configurati correttamente. I tuoi Makefile (o qualsiasi altra cosa) dovrebbero essere impostati per notare dove sono in esecuzione e dovrebbero rifiutarsi di ri-derivare i sorgenti a meno che non sappiano che sono in esecuzione in un sito di compilazione sicuro.

Se fa parte del codice sorgente, dovrebbe essere inserito nel controllo del codice sorgente indipendentemente da chi o cosa lo genera. Si desidera che il controllo del codice sorgente rifletta lo stato corrente del sistema senza doverlo rigenerare.

Avere assolutamente il codice generato nel controllo del codice sorgente, per molte ragioni. Sto ribadendo ciò che molte persone hanno già detto, ma alcuni motivi per cui lo farei sono

1. Con i file di codice nel controllo del codice sorgente, sarai potenzialmente in grado di compilare il codice senza usare il passaggio di pre-compilazione di Visual Studio.
2. Quando esegui un confronto completo tra due versioni, sarebbe bello sapere se il codice generato è cambiato tra questi due tag, senza doverlo controllare manualmente.
3. Se il generatore di codice stesso cambia, ti consigliamo di assicurarti che le modifiche al codice generato cambino in modo appropriato. cioè, se il tuo generatore cambia, ma l'output non dovrebbe cambiare, allora quando andrai a eseguire il commit del tuo codice, non ci saranno differenze tra ciò che è stato generato in precedenza e ciò che è nel codice generato ora.

Lascerei i file generati fuori da un albero dei sorgenti, ma li inserirò in un albero di compilazione separato.

ad esempio, il flusso di lavoro è

1. checkin / out / modifica / unisci normalmente la sorgente (senza alcun file generato)
2. Nelle occasioni appropriate, controlla l'albero dei sorgenti in un albero di compilazione pulito
3. Dopo una compilazione, archiviare tutti i file "importanti" (file sorgente "reali", eseguibili + file sorgente generato) che devono essere presenti per scopi di controllo / regolamentazione. Questo ti dà una cronologia di tutto il codice generato appropriato + eseguibili + qualunque cosa, con incrementi di tempo correlati a release / snapshot di test, ecc. E disaccoppiati dallo sviluppo quotidiano.

Probabilmente ci sono buoni modi in Subversion / Mercurial / Git / etc per legare insieme la cronologia dei file sorgenti reali in entrambi i posti.

Sembra che ci siano opinioni molto forti e convincenti da entrambe le parti. Consiglierei di leggere tutte le risposte più votate e poi di decidere quali argomenti si applicano al tuo caso specifico.

AGGIORNAMENTO: Ho posto questa domanda poiché credevo davvero che ci fosse una risposta definitiva. Guardando tutte le risposte, potrei dire con un alto livello di certezza, che non esiste una risposta del genere. La decisione dovrebbe essere presa in base a più di un parametro. Leggere le altre risposte potrebbe fornire un'ottima linea guida per i tipi di domande che dovresti porci quando devi decidere su questo problema.