Devo memorizzare il codice generato nel controllo del codice sorgente


106

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?


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 risposte di seguito potrebbe fornire un'ottima linea guida per i tipi di domande che dovresti chiederti quando devi decidere su questo problema.

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


1
Si può essere interessati a una domanda simile: stackoverflow.com/questions/739391/...
mouviciel

Vorrei dire che, nel caso di SubSonic, potrebbe essere interessante mantenere il controllo del codice sorgente come un modo per tenere traccia facilmente anche di (alcune) modifiche al database, nel caso in cui non si disponga di altri modi per tracciare la cronologia di il tuo database.
Earlz

1
A mio avviso, il problema principale è che diversi sviluppatori non ottengono lo stesso risultato quando generano le classi. La configurazione per generarli dovrebbe essere archiviata e fornire build coerenti in tutti gli ambienti di sviluppo.
nawroth

1
Non so come farlo, tuttavia penso che questa domanda dovrebbe essere chiusa ora poiché è troppo aperta all'opinione e alla discussione senza essere strettamente correlata a specifici sistemi di controllo del codice sorgente oa specifici tipi di file generati.
Chris Halcrow

Questa è una grande domanda, ma è troppo basata sulle opinioni per SO, come indicato dalle molteplici risposte contrastanti, e dal commento dell'OP in questo senso.
Flimzy

Risposte:


48

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


43
Non sono d'accordo con "devi fare un commit ogni volta che costruisci". Ciò non dovrebbe causare alcun commit aggiuntivo perché l'unica cosa che dovrebbe influenzare il commit è una modifica al codice che quindi cambia la sorgente generata. Quindi, in effetti, devi eseguire il commit del codice generato solo quando stai già effettuando il commit della modifica all'origine del codice generato.
JaredPar

5
D'accordo con JaredPar. Anche il tuo generatore di codice potrebbe essere uno strumento esterno e, se lo aggiorni, il codice generato potrebbe cambiare e quindi potrebbe essere necessario eseguire il commit delle modifiche. Ma in questo caso vorrei davvero vedere comunque i cambiamenti nel controllo del codice sorgente.
furgone

Strumenti diversi possono generare fonti diverse (almeno possono differire nei commenti o nella formattazione del codice). Ad esempio, Idea aggiunge il commento "generato dall'idea" mentre Eclipse no.
Petr Gladkikh

1
L'opinione è divisa, contrassegnare questa risposta come una risposta trasmetterebbe un messaggio sbagliato.
Espresso

34

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.


18
Non è un vantaggio: dal momento che il codice che lo ha creato è archiviato, hai già "tutto ciò che scrivi" disponibile per i futuri sviluppatori.
Shane C. Mason,

13
@Shane, sono fortemente in disaccordo. Avere il codice che lo ha creato non significa avere il codice. Qualsiasi passaggio aggiuntivo che deve essere incluso per la generazione è un fastidio aggiuntivo quando si rintraccia un bug. È molto più semplice passare attraverso la cronologia del codice piuttosto che controllare N versioni del file e rigenerare N versioni del codice generato.
JaredPar

10
A volte è utile avere i file generati nel controllo del codice sorgente. Ad esempio, se aggiorni un componente, in questo caso SubSonic, puoi facilmente rilevare i cambiamenti nella sorgente generata. Questo potrebbe essere utile per rintracciare bug e problemi. Non aggiungerei tutto il codice generato al controllo del codice sorgente. A volte è molto utile. La maggior parte dei sistemi di controllo del codice sorgente ti consentirà di fare una differenza per vedere se i file sono davvero cambiati, anche se forse è più un processo manuale se devi ripristinare manualmente i file anche se l'unica modifica è il timestamp.
Ryan

18
Con questa logica dovresti anche controllare i tuoi file oggetto compilati, le librerie e gli eseguibili.
Laurence Gonsalves,

9
Che tipo di generatore di codice stai usando dove "la lingua originale non ha senso"? Per quanto riguarda il punto di tenere traccia di quali versioni dei tuoi strumenti stai utilizzando per creare ogni versione del codice, devi già risolvere quel problema per l'intera toolchain. Dopo tutto, come ti aspetti di eseguire il backport di un bug su una versione precedente del tuo prodotto a meno che tu non sappia quale versione del compilatore e del linker stavi utilizzando all'epoca? Un generatore di codice non è diverso dal compilatore C ++ / Java / C #. Il fatto che tu possa leggere il suo output è irrilevante: il suo input è la fonte.
Laurence Gonsalves

31

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.


3
Inoltre, sugli aggiornamenti, è possibile ottenere strani conflitti che VCS considererà necessari per la risoluzione, ma che in realtà si risolveranno da soli la prossima volta che si crea. Per non parlare del disordine nei registri, che considero anche peggiore del disordine nel tuo albero locale.
rmeador

5
Dove mi trovo, non si presentano come "cambiati" a meno che non siano davvero cambiati. Se sono stati rigenerati ma hanno ancora lo stesso contenuto quindi l'unica cosa diversa sono le date di creazione / modifica del file, il sistema pensa che non siano cambiate e tutto va bene.
Joel Coehoorn

+1 Voglio essere responsabile solo del codice che scrivo, non del codice generato da qualche toolkit che potrebbe aver avuto problemi in quel momento che ora è impossibile duplicare (ma qualcuno potrebbe passare molto tempo a provare.)
dkretz

4
Ho visto strumenti di generazione automatica che aggiornano il timestamp ogni volta che vengono eseguiti. Li maledico.
Kieveli

25

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.


20

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.


1
Cordiali saluti, ho condiviso uno script per fare il confronto qui: stackoverflow.com/a/16754923/105137
kostmo

17

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.


15

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 è.


14

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?


8

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.


6

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 ...


5

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!


4

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.


2
Commenti simili si applicano ai file generati da autoconf / automake; la maggior parte delle persone archivia i propri file ./configure e Makefile.in, anche se sono generati - la maggior parte degli utenti (e molti sviluppatori) non avrà bisogno di ricostruirli e, controllando quei file, non avrai bisogno di autotools installati costruire.
Stobor

1
Sì, memorizziamo anche il nostro script di configurazione e le nostre dipendenze Make generate nel controllo della versione.
Phil Miller

4

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.


3

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.


3

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.


2

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.


"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" \ n Questo è tutto ciò che vorrei archiviare. Se costruisci il tuo compilatore dal sorgente su ogni macchina dello sviluppatore come parte della stessa build delle tue app (ad esempio: digiti "make" una volta), controlla il sorgente. Se non lo fai, controlla i binari
KeyserSoze

2

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.


Fai un punto interessante e non prendi personalmente il voto negativo, è solo che per scopi pratici in ambienti di sviluppo spesso frenetici, questo non è pratico. Perché in ogni caso il codice generato automaticamente trasporterebbe dati relativi al contenuto o all'IP? Suggerirei che i client in generale non sarebbero in grado di cogliere le implicazioni del codice generato automaticamente per il controllo del codice sorgente e probabilmente in generale non dovrebbe essere offerta questa opzione. IMHO è troppo overhead e spese per occuparsi di una situazione legale ipotetica e improbabile.
Chris Halcrow

Nel dominio in cui mi trovo attualmente, l'assicurazione che il nostro cliente (molto grande) conserva TUTTO per un minimo di 10 anni. Creiamo strumenti sofisticati per generare servizi WCF. I clienti mantengono il codice generato, i modelli, il tutto. Ma questo è il mio cliente. Immagino che tu abbia perso il punto che stavo dicendo che "Dipende dalle esigenze del cliente" e "in qualunque modo tu decida se non stai coinvolgendo gli esperti in materia della decisione, probabilmente ti sbagli." Se in qualche modo questa è una cattiva risposta, o ti fa sentire meglio dando un -1, felice di aver aiutato. Fare riferimento a "womp" nel commento sopra la mia risposta.
James Fleming

2

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.


2

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


1

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.


5
Adoro la guida di -1. Se non sei d'accordo, non votare a favore: vota le altre risposte. Salva i voti negativi per una risposta sbagliata. Questa è una domanda soggettiva.
womp

1

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.


2
Verifichi i file oggetto (.o)?
KeyserSoze

1

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.


Non sono d'accordo. Se si fanno un processo manuale, che si ottiene rotto, e nessuno noterà finché non arriva il momento di eseguire nuovamente esso. Se viene generato ogni giorno sui server di compilazione (e su ogni macchina degli sviluppatori quando esegue una build "pulita"), non rimarrai sorpreso.
KeyserSoze

Se il codice del livello di accesso ai dati viene archiviato nel controllo del codice sorgente, non dovrebbero esserci sorprese perché le persone saranno costrette ad aggiornare il codice. Se qualcuno cambia la versione dello strumento di generazione del codice sulla macchina di compilazione e gli sviluppatori hanno vecchie versioni sulla loro macchina di sviluppo (un ramo di codice diverso, forse), allora ci saranno mal di testa. Sto suggerendo di rimuovere la fase di generazione del codice dal processo di compilazione, poiché non sono i manutentori del generatore di codice.
benson

1

(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.


1

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.


"senza doverlo rigenerare." quindi controlli i binari compilati? Controlli anche una versione della piattaforma di destinazione? Quella strategia non scalerà bene. :(
dss539

1
E questo mi fa guadagnare un voto negativo ?? Ovviamente non controlli i binari compilati (a meno che non provengano da librerie di terze parti) poiché possono essere rigenerati dal tuo codice sorgente. Stavo parlando di dover rigenerare il codice generato non i binari. Ma hey, se vuoi interpretare male quello che sto dicendo, vai avanti ...
mezoid

Questa risposta non valeva un voto negativo! Per lo meno, sembra opportuno mettere il codice generato in SC (magari in un luogo chiaramente identificato) in modo che tu possa almeno confrontare l'hash del codice utilizzato per generare l'oggetto con il nuovo codice che stai per generare per una nuova build. Interessante quanto sia polarizzante questa domanda.
rp.

1

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.

1
E il tuo stesso generatore di codice non è nel controllo del codice sorgente perché ...?
Jeffrey Hantin

@ Jeffrey: non ho mai detto che il generatore di codice non fosse nel controllo del codice sorgente.
Joe Enos

Lo so, sto solo scherzando. :-) Ho scoperto che molti generatori di codice basati su CodeDom amano produrre il loro output in ordine casuale, quindi per la ripetibilità (e quindi la capacità di dire prontamente se il codice generato cambia da esecuzione a esecuzione) I ' ho scritto una routine che ordina i contenuti di a CodeCompileUnitin un ordine canonico.
Jeffrey Hantin

0

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.


0

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.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.