Soll ich generierten Code in der Quellcodeverwaltung speichern?

Dies ist eine Debatte, an der ich teilnehme. Ich würde gerne mehr Meinungen und Standpunkte erhalten.

Wir haben einige Klassen, die in der Erstellungszeit generiert werden, um DB-Operationen zu verarbeiten (in diesem speziellen Fall mit SubSonic, aber ich denke nicht, dass dies für die Frage sehr wichtig ist). Die Generierung wird in Visual Studio als vorgefertigter Schritt festgelegt. Jedes Mal, wenn ein Entwickler (oder der offizielle Build-Prozess) einen Build ausführt, werden diese Klassen generiert und dann in das Projekt kompiliert.

Nun behaupten einige Leute, dass das Speichern dieser Klassen in der Quellcodeverwaltung Verwirrung stiften könnte, falls der Code, den Sie erhalten, nicht mit dem übereinstimmt, der in Ihrer eigenen Umgebung generiert worden wäre.

Ich hätte gerne eine Möglichkeit, den Verlauf des Codes zurückzuverfolgen, auch wenn dieser normalerweise als Black Box behandelt wird.

Irgendwelche Argumente oder Gegenargumente?

Ich werde an dieser Stelle aus den oben genannten Gründen keine akzeptierte Antwort auswählen.

Das Speichern in der Quellcodeverwaltung ist schwieriger als es sich lohnt.

Sie müssen jedes Mal ein Commit ausführen, wenn Sie einen Build ausführen, damit er einen beliebigen Wert aufweist.

Im Allgemeinen lassen wir generierten Code (idl, jaxb usw.) außerhalb der Quellcodeverwaltung, wo ich arbeite, und es war nie ein Problem

Setzen Sie es in die Quellcodeverwaltung. Der Vorteil, dass der Verlauf von allem, was Sie schreiben, für zukünftige Entwickler verfügbar ist, überwiegt den geringen Aufwand, der nach einer Synchronisierung gelegentlich neu erstellt wird.

Jedes Mal, wenn ich Änderungen an einem Quellbaum in meinem persönlichen Repo anzeigen möchte, werden alle "generierten Dateien" als geändert angezeigt und müssen angepasst werden.

Ich würde es vorziehen, eine übersichtlichere Liste von Änderungen zu haben, die nur echte Aktualisierungen enthalten, die durchgeführt wurden, und keine automatisch generierten Änderungen.

Lassen Sie sie weg und fügen Sie nach einem Build jeder generierten Datei ein "Ignorieren" hinzu.

Betrachten Sie es so: Checken Sie Ihre Objektdateien in die Quellcodeverwaltung ein? Generierte Quelldateien sind Build-Artefakte wie Objektdateien, Bibliotheken und ausführbare Dateien. Sie sollten gleich behandelt werden. Die meisten würden argumentieren, dass Sie generierte Objektdateien und ausführbare Dateien nicht in die Quellcodeverwaltung einchecken sollten. Die gleichen Argumente gelten für die generierte Quelle.

Wenn Sie sich die historische Version einer generierten Datei ansehen müssen, können Sie sie mit der historischen Version ihrer Quellen synchronisieren und neu erstellen.

Das Einchecken generierter Dateien jeglicher Art in die Quellcodeverwaltung erfolgt analog zur Denormalisierung der Datenbank. Es gibt gelegentlich Gründe, dies zu tun (normalerweise aus Gründen der Leistung). Dies sollte jedoch nur mit großer Sorgfalt erfolgen, da es viel schwieriger wird, die Richtigkeit und Konsistenz aufrechtzuerhalten, sobald die Daten denormalisiert sind.

Ich würde sagen, dass Sie vermeiden sollten, generierten Code (oder andere Artefakte) zur Quellcodeverwaltung hinzuzufügen. Wenn der generierte Code für die angegebene Eingabe identisch ist, können Sie einfach die Versionen überprüfen, die Sie unterscheiden möchten, und den Code zum Vergleich generieren.

Ich nenne das DRY-Prinzip. Wenn Sie bereits die "Quelldateien" im Repository haben, mit denen diese Codedateien beim Erstellen generiert werden, muss nicht derselbe Code "zweimal" festgeschrieben werden.

Außerdem können Sie auf diese Weise einige Probleme vermeiden, wenn beispielsweise die Codegenerierung eines Tages unterbrochen wird.

Nein, aus drei Gründen.

1. Der Quellcode ist alles Notwendige und Ausreichende, um einen Schnappschuss Ihrer Anwendung zu einem aktuellen oder vorherigen Zeitpunkt zu reproduzieren - nicht mehr und nicht weniger. Dies impliziert unter anderem, dass jemand für alles verantwortlich ist, was eingecheckt wurde. Im Allgemeinen bin ich froh, für den Code verantwortlich zu sein, den ich schreibe, aber nicht für den Code, der als Folge dessen generiert wird, was ich schreibe.

2. Ich möchte nicht, dass jemand versucht ist, einen Build aus Primärquellen zu verknüpfen, indem er Zwischencode verwendet, der möglicherweise aktuell ist oder nicht (und was noch wichtiger ist, für den ich keine Verantwortung übernehmen möchte). Und nicht auch? Es ist verlockend für einige Leute, in einen bedeutungslosen Prozess über das Debuggen von Konflikten in Zwischencode verwickelt zu werden, der auf partiellen Builds basiert.

3. Sobald es in der Quellcodeverwaltung ist, übernehme ich die Verantwortung für a. es ist da, b. es ist aktuell und c. es ist zuverlässig in alles andere integriert. Dazu gehört das Entfernen, wenn ich es nicht mehr benutze. Je weniger von dieser Verantwortung, desto besser.

Ich denke wirklich nicht, dass Sie sie einchecken sollten.

Sicherlich wird jede Änderung des generierten Codes entweder Rauschen sein - Änderungen zwischen Umgebungen oder Änderungen aufgrund von etwas anderem - z. B. einer Änderung in Ihrer Datenbank. Wenn sich die Erstellungsskripte Ihrer Datenbank (oder andere Abhängigkeiten) in der Quellcodeverwaltung befinden, warum benötigen Sie dann auch die generierten Skripte?

Die allgemeine Regel lautet " Nein" . Wenn das Generieren des Codes jedoch einige Zeit in Anspruch nimmt (aufgrund von DB-Zugriff, Webdiensten usw.), möchten Sie möglicherweise eine zwischengespeicherte Version in der Quellcodeverwaltung speichern und allen die Schmerzen ersparen.

Ihr Tool muss sich dessen ebenfalls bewusst sein und bei Bedarf das Auschecken aus der Quellcodeverwaltung übernehmen. Zu viele Tools entscheiden sich ohne Grund für das Auschecken aus der Quellcodeverwaltung.
Ein gutes Tool verwendet die zwischengespeicherte Version, ohne sie zu berühren (oder die Zeitschritte in der Datei zu ändern).

Außerdem müssen Sie eine große Warnung in den generierten Code einfügen, damit die Benutzer die Datei nicht ändern können. Eine Warnung oben reicht nicht aus. Sie müssen sie alle Dutzend Zeilen wiederholen.

Wir speichern auch keinen generierten DB-Code: Da er generiert wird, können Sie ihn nach Belieben in einer beliebigen Version aus den Quelldateien abrufen. Das Speichern wäre wie das Speichern von Bytecode oder ähnlichem.

Jetzt müssen Sie sicherstellen, dass der in einer bestimmten Version verwendete Codegenerator verfügbar ist! Neuere Versionen können unterschiedlichen Code generieren ...

Lass es aus.

Wenn Sie generierte Dateien einchecken, machen Sie etwas falsch. Was falsch ist, kann sich unterscheiden. Es kann sein, dass Ihr Erstellungsprozess ineffizient ist oder etwas anderes, aber ich kann nicht sehen, dass es jemals eine gute Idee ist. Der Verlauf sollte den Quelldateien zugeordnet werden, nicht den generierten.

Es bereitet nur Kopfschmerzen für Leute, die dann versuchen, Unterschiede zu lösen, die Dateien zu finden, die nicht mehr vom Build generiert werden, und sie dann zu löschen usw.

Eine Welt voller Schmerzen erwartet diejenigen, die generierte Dateien einchecken!

Es gibt einen Sonderfall, in dem Sie Ihre generierten Dateien einchecken möchten: Wenn Sie möglicherweise auf Systemen aufbauen müssen, auf denen keine Tools zum Generieren der anderen Dateien verfügbar sind. Das klassische Beispiel dafür und eines, mit dem ich arbeite, ist Lex- und Yacc-Code. Da wir ein Laufzeitsystem entwickeln, das auf einer Vielzahl von Plattformen und Architekturen erstellt und ausgeführt werden muss, können wir uns nur auf Zielsysteme mit C- und C ++ - Compilern verlassen, nicht auf die Tools, die zum Generieren des Lexing- / Parsing-Codes für unsere Schnittstellendefinition erforderlich sind Übersetzer. Wenn wir also unsere Grammatik ändern, checken wir den generierten Code ein, um ihn zu analysieren.

etwas spät ankommen ... sowieso ...

Würden Sie die Zwischendatei des Compilers in die Versionskontrolle der Quelle einfügen? Bei der Codegenerierung ist der Quellcode per Definition die Eingabe des Generators, während der generierte Code als Zwischendatei zwischen der "echten" Quelle und der erstellten Anwendung betrachtet werden kann.

Ich würde also sagen: Setzen Sie den generierten Code nicht der Versionskontrolle unter, sondern den Generator und seine Eingabe.

Konkret arbeite ich mit einem Codegenerator, den ich geschrieben habe: Ich musste den generierten Quellcode nie unter Versionskontrolle halten. Ich würde sogar sagen, dass ich, da der Generator einen bestimmten Reifegrad erreicht hat, den Inhalt des generierten Codes nicht beobachten musste, obwohl sich die Eingabe (zum Beispiel die Modellbeschreibung) geändert hat.

In einigen Projekten füge ich generierten Code zur Quellcodeverwaltung hinzu, aber das hängt wirklich davon ab. Meine grundlegende Richtlinie lautet: Wenn der generierte Code ein wesentlicher Bestandteil des Compilers ist, werde ich ihn nicht hinzufügen. Wenn der generierte Code von einem externen Tool stammt, wie in diesem Fall SubSonic, würde ich if zur Quellcodeverwaltung hinzufügen. Wenn Sie die Komponente regelmäßig aktualisieren, möchte ich die Änderungen in der generierten Quelle wissen, falls Fehler oder Probleme auftreten.

In Bezug auf den generierten Code, der eingecheckt werden muss, besteht ein Worst-Case-Szenario darin, die Dateien manuell zu differenzieren und die Dateien bei Bedarf zurückzusetzen. Wenn Sie svn verwenden, können Sie in svn einen Pre-Commit-Hook hinzufügen, um ein Commit zu verweigern, wenn sich die Datei nicht wirklich geändert hat.

Die Aufgabe des Konfigurationsmanagements (von dem die Versionskontrolle nur ein Teil ist) besteht darin, Folgendes zu tun:

• Wissen, welche Änderungen und Fehlerbehebungen in jedem gelieferten Build vorgenommen wurden.
• Sie können genau jeden gelieferten Build reproduzieren, beginnend mit dem ursprünglichen Quellcode. Automatisch generierter Code zählt unabhängig von der Sprache nicht als "Quellcode".

Die erste stellt sicher, dass, wenn Sie dem Client oder Endbenutzer mitteilen, dass "der Fehler, den Sie letzte Woche gemeldet haben, behoben ist und die neue Funktion hinzugefügt wurde", diese zwei Stunden später nicht zurückkommen und "Nein, hat es nicht" sagen. Es stellt auch sicher, dass sie nicht sagen "Warum macht es X? Wir haben nie nach X gefragt".

Der zweite bedeutet, dass Sie, wenn der Client oder Endbenutzer einen Fehler in einer Version meldet, die Sie vor einem Jahr herausgegeben haben, zu dieser Version zurückkehren, den Fehler reproduzieren, beheben und beweisen können, dass Ihr Fehler den Fehler behoben hat, anstatt ihn zu beseitigen Einige Störungen des Compilers und andere Korrekturen.

Dies bedeutet, dass Ihr Compiler, Ihre Bibliotheken usw. ebenfalls Teil von CM sein müssen.

Um Ihre Frage zu beantworten: Wenn Sie alle oben genannten Aufgaben ausführen können, müssen Sie keine Zwischendarstellungen aufzeichnen, da Sie garantiert trotzdem die gleiche Antwort erhalten. Wenn Sie nicht alle oben genannten Punkte ausführen können, sind alle Wetten ungültig, da Sie niemals garantieren können, dass Sie zweimal dasselbe tun und dieselbe Antwort erhalten. Sie können also auch alle Ihre .o-Dateien unter Versionskontrolle stellen.

Es kommt wirklich darauf an. Letztendlich ist es das Ziel, das, was Sie hatten, bei Bedarf reproduzieren zu können. Wenn Sie Ihre Binärdateien genau neu generieren können, müssen Sie sie nicht speichern. Sie müssen sich jedoch daran erinnern, dass Sie zum erneuten Erstellen Ihrer Inhalte wahrscheinlich Ihre genaue Konfiguration benötigen, mit der Sie sie ursprünglich erstellt haben. Dies bedeutet nicht nur Ihren Quellcode, sondern auch Ihre Build-Umgebung, Ihre IDE und möglicherweise sogar andere Bibliotheken , Generatoren oder ähnliches, in der genauen Konfiguration (Versionen), die Sie verwendet haben.

Ich bin in Projekten auf Probleme gestoßen, bei denen wir unsere Build-Umgebung auf neuere Versionen oder sogar auf Versionen anderer Anbieter aktualisiert haben, bei denen wir nicht in der Lage waren, die genauen Binärdateien wiederherzustellen, die wir zuvor hatten. Dies ist ein echtes Problem, wenn die zu verwendenden Binärdateien von einer Art Hash abhängen, insbesondere in einer gesicherten Umgebung, und die neu erstellten Dateien sich aufgrund von Compiler-Upgrades oder was auch immer unterscheiden.

Würden Sie generierten Code speichern? Ich würde nein sagen. Die freigegebenen Binärdateien oder Ergebnisse, einschließlich der Tools, mit denen Sie sie reproduziert haben, würde ich speichern. Und dann müssen sie nicht in der Quellcodeverwaltung gespeichert werden. Erstellen Sie einfach eine gute Sicherung dieser Dateien.

Die richtige Antwort lautet "Es kommt darauf an". Es hängt von den Bedürfnissen des Kunden ab. Wenn Sie Code auf eine bestimmte Version zurücksetzen und ohne diese externen Audits standhalten können, sind Sie immer noch nicht auf festem Boden. Als Entwickler müssen wir nicht nur "Rauschen", Schmerzen und Speicherplatz berücksichtigen, sondern auch die Tatsache, dass wir die Aufgabe haben, geistiges Eigentum zu generieren, und dass es rechtliche Konsequenzen geben kann. Könnten Sie einem Richter beweisen, dass Sie eine Website genau so regenerieren können, wie es ein Kunde vor zwei Jahren gesehen hat?

Ich schlage nicht vor, dass Sie gen'd-Dateien speichern oder nicht speichern, unabhängig davon, wie Sie entscheiden, ob Sie die Fachexperten nicht in die Entscheidung einbeziehen, bei der Sie wahrscheinlich falsch liegen.

Meine zwei Cent.

Es gibt gute Argumente für und gegen hier. Für die Aufzeichnung baue ich das T4-Generierungssystem in Visual Studio und unsere standardmäßige Standardoption bewirkt, dass generierter Code eingecheckt wird. Sie müssen etwas härter arbeiten, wenn Sie nicht einchecken möchten.

Für mich ist es wichtig, die generierte Ausgabe zu unterscheiden, wenn entweder die Eingabe oder der Generator selbst aktualisiert wird.

Wenn Sie Ihre Ausgabe nicht eingecheckt haben, müssen Sie eine Kopie des gesamten generierten Codes erstellen, bevor Sie einen Generator aktualisieren oder die Eingabe ändern, um diese mit der Ausgabe der neuen Version vergleichen zu können. Ich denke, dies ist ein ziemlich langwieriger Prozess, aber bei eingecheckten Ausgaben ist es einfach, die neue Ausgabe vom Repository zu unterscheiden.

An dieser Stelle ist es vernünftig zu fragen: "Warum interessieren Sie sich für Änderungen im generierten Code?" (Insbesondere im Vergleich zum Objektcode.) Ich glaube, es gibt einige Hauptgründe, die eher auf den aktuellen Stand der Technik als auf ein inhärentes Problem zurückzuführen sind.

1. Sie erstellen handgeschriebenen Code, der eng mit dem generierten Code verknüpft ist. Dies ist heutzutage bei obj-Dateien im Großen und Ganzen nicht der Fall. Wenn sich der generierte Code ändert, muss leider häufig handgeschriebener Code geändert werden, damit er übereinstimmt. Leute beobachten oft kein hohes Maß an Abwärtskompatibilität mit Erweiterungspunkten im generierten Code.

2. Generierter Code ändert einfach sein Verhalten. Sie würden dies von einem Compiler nicht tolerieren, aber fairerweise zielt ein Codegenerator auf Anwendungsebene auf ein anderes Problembereich mit einer größeren Auswahl akzeptabler Lösungen ab. Es ist wichtig zu sehen, ob Annahmen, die Sie über das vorherige Verhalten getroffen haben, jetzt gebrochen sind.

3. Sie vertrauen der Ausgabe Ihres Generators von Release zu Release einfach nicht zu 100%. Generator-Tools bieten viel Wert, auch wenn sie nicht mit der Genauigkeit Ihres Compiler-Anbieters erstellt und gewartet werden. Release 1.0 war für Ihre Anwendung möglicherweise perfekt stabil, aber 1.1 hat jetzt einige Probleme für Ihren Anwendungsfall. Alternativ ändern Sie die Eingabewerte und stellen fest, dass Sie ein neues Stück des Generators trainieren, das Sie zuvor noch nicht verwendet haben - möglicherweise werden Sie von den Ergebnissen überrascht.

Im Wesentlichen kommt es bei all diesen Dingen auf die Tool-Reife an - die meisten Code-Generatoren für Geschäftsanwendungen liegen nicht in der Nähe des Niveaus, das Compiler oder sogar Tools auf Lex / Yacc-Ebene seit Jahren haben.

Beide Seiten haben gültige und vernünftige Argumente, und es ist schwierig, sich auf etwas Gemeinsames zu einigen. Versionskontrollsysteme (VCS) verfolgen die Dateien, die Entwickler darin abgelegt haben, und gehen davon aus, dass die Dateien in VCS von Entwicklern von Hand erstellt wurden und Entwickler an der Historie und dem Wechsel zwischen jeder Überarbeitung der Dateien interessiert sind. Diese Annahme gleicht die beiden Konzepte aus: "Ich möchte diese Datei beim Auschecken erhalten." und "Ich bin an der Änderung dieser Datei interessiert."

Nun könnten die Argumente von beiden Seiten folgendermaßen umformuliert werden:

• "Ich möchte alle diese generierten Dateien beim Auschecken abrufen, da ich nicht das Tool habe, um sie auf diesem Computer zu generieren."
• "Ich sollte sie nicht in VCS einfügen, da ich nicht an der Änderung dieser Datei interessiert bin."

Glücklicherweise scheinen sich die beiden Anforderungen nicht grundlegend zu widersprechen. Mit einer gewissen Erweiterung der aktuellen VCS sollte es möglich sein, beides zu haben. Mit anderen Worten, es ist ein falsches Dilemma. Wenn wir eine Weile darüber nachdenken, ist es nicht schwer zu erkennen, dass das Problem auf der Annahme beruht, dass VCSs gelten. VCSs sollten die von Entwicklern handgefertigten Dateien von Dateien unterscheiden, die nicht von Entwicklern handgefertigt wurden, sondern sich zufällig in diesem VCS befinden. Für die erste Kategorie von Dateien, die wir normalerweise als Quelldateien (Code) bezeichnen, haben VCSs jetzt hervorragende Arbeit geleistet. Für die letztere Kategorie hatten VCS meines Wissens noch kein solches Konzept.

Zusammenfassung

Ich werde Git als ein Beispiel nehmen, um zu veranschaulichen, was ich meine.

• git status sollte standardmäßig keine generierten Dateien anzeigen.
• git commit sollte generierte Dateien als Schnappschuss enthalten.
• git diff sollte standardmäßig keine generierten Dateien anzeigen.

PS

Git-Hooks könnten als Problemumgehung verwendet werden, aber es wäre großartig, wenn Git dies nativ unterstützt. gitignoreentspricht nicht unseren Anforderungen, da ignorierte Dateien nicht in VCSs gespeichert werden.enter code here

Ich würde dafür argumentieren. Wenn Sie einen kontinuierlichen Integrationsprozess verwenden, der den Code auscheckt, die Build-Nummer ändert, die Software erstellt und dann testet, ist es einfacher und einfacher, diesen Code nur als Teil Ihres Repositorys zu haben.

Darüber hinaus ist es Bestandteil jedes "Schnappschusses", den Sie von Ihrem Software-Repository erstellen. Wenn es Teil der Software ist, sollte es Teil des Repositorys sein.

Ich würde sagen, dass Sie es ja unter Quellcodeverwaltung stellen möchten. Vom Standpunkt des Konfigurationsmanagements aus muss ALLES, was zur Erstellung eines Software-Builds verwendet wird, gesteuert werden, damit es neu erstellt werden kann. Ich verstehe, dass generierter Code leicht neu erstellt werden kann, aber es kann argumentiert werden, dass er nicht gleich ist, da die Datums- / Zeitstempel zwischen den beiden Builds unterschiedlich sind. In einigen Bereichen wie der Regierung ist häufig erforderlich, dass dies getan wird.

Im Allgemeinen muss der generierte Code nicht in der Quellcodeverwaltung gespeichert werden, da der Revisionsverlauf dieses Codes anhand des Revisionsverlaufs des Codes verfolgt werden kann, der ihn generiert hat!

Es scheint jedoch, dass das OP den generierten Code als Datenzugriffsschicht der Anwendung verwendet, anstatt manuell einen zu schreiben. In diesem Fall würde ich den Erstellungsprozess ändern und den Code der Quellcodeverwaltung übergeben, da er eine kritische Komponente des Laufzeitcodes ist. Dadurch wird auch die Abhängigkeit vom Tool zur Codegenerierung aus dem Erstellungsprozess entfernt, falls die Entwickler unterschiedliche Versionen des Tools für unterschiedliche Zweige verwenden müssen.

Es scheint, dass der Code anstelle jedes Builds nur einmal generiert werden muss. Wenn ein Entwickler die Art und Weise, wie ein Objekt auf die Datenbank zugreift, hinzufügen / entfernen / ändern muss, sollte der Code erneut generiert werden, genau wie manuelle Änderungen. Dies beschleunigt den Erstellungsprozess, ermöglicht manuelle Optimierungen an der Datenzugriffsschicht und der Verlauf der Datenzugriffsschicht wird auf einfache Weise beibehalten.

Ich werde (bedauerlicherweise) viele abgeleitete Quellen unter Quellcodeverwaltung stellen, weil ich remote mit Leuten zusammenarbeite, die entweder nicht die Mühe haben, eine ordnungsgemäße Build-Umgebung einzurichten, oder die nicht über die Fähigkeiten verfügen, sie so einzurichten, dass die abgeleitete Quellen sind genau richtig aufgebaut. (Und wenn es um Gnu-Autotools geht, bin ich selbst einer dieser Leute! Ich kann nicht mit drei verschiedenen Systemen arbeiten, von denen jedes mit einer anderen Version von Autotools funktioniert - und nur mit dieser Version.)

Diese Art von Schwierigkeit betrifft wahrscheinlich eher Teilzeit-Open-Source-Projekte als freiwillige Projekte, bei denen die Person, die die Rechnungen bezahlt, auf einer einheitlichen Bauumgebung bestehen kann.

Wenn Sie dies tun, verpflichten Sie sich grundsätzlich, die abgeleiteten Dateien nur an einem Standort oder nur an ordnungsgemäß konfigurierten Standorten zu erstellen. Ihre Makefiles (oder was auch immer) sollten so eingerichtet sein, dass sie feststellen, wo sie ausgeführt werden, und sich weigern, Quellen erneut abzuleiten, es sei denn, sie wissen, dass sie an einem sicheren Build-Standort ausgeführt werden.

Wenn es Teil des Quellcodes ist, sollte es in die Quellcodeverwaltung gestellt werden, unabhängig davon, wer oder was es generiert. Sie möchten, dass Ihre Quellcodeverwaltung den aktuellen Status Ihres Systems widerspiegelt, ohne ihn neu generieren zu müssen.

Haben Sie den generierten Code aus vielen Gründen unbedingt in der Quellcodeverwaltung. Ich wiederhole, was viele Leute bereits gesagt haben, aber einige Gründe, warum ich es tun würde, sind

1. Mit Codedateien in der Quellcodeverwaltung können Sie den Code möglicherweise kompilieren, ohne Ihren Visual Studio-Vorerstellungsschritt zu verwenden.
2. Wenn Sie einen vollständigen Vergleich zwischen zwei Versionen durchführen, wäre es schön zu wissen, ob sich der generierte Code zwischen diesen beiden Tags geändert hat, ohne ihn manuell überprüfen zu müssen.
3. Wenn sich der Codegenerator selbst ändert, sollten Sie sicherstellen, dass sich die Änderungen am generierten Code entsprechend ändern. Wenn sich Ihr Generator ändert, sich die Ausgabe jedoch nicht ändern soll, gibt es beim Festschreiben Ihres Codes keine Unterschiede zwischen dem, was zuvor generiert wurde, und dem, was jetzt im generierten Code enthalten ist.

Ich würde generierte Dateien aus einem Quellbaum herauslassen, sie aber in einem separaten Build-Baum ablegen.

zB Workflow ist

1. Quelle normal ein- / auschecken / ändern / zusammenführen (ohne generierte Dateien)
2. Überprüfen Sie bei geeigneten Gelegenheiten den Quellbaum in einen sauberen Build-Baum
3. Checken Sie nach einem Build alle "wichtigen" Dateien ("echte" Quelldateien, ausführbare Dateien + generierte Quelldatei) ein, die für Prüfungs- / Regulierungszwecke vorhanden sein müssen. Auf diese Weise erhalten Sie einen Verlauf aller geeigneten generierten Codes + ausführbaren Dateien + was auch immer, zu Zeitschritten, die sich auf Releases / Test-Snapshots usw. beziehen und von der täglichen Entwicklung entkoppelt sind.

In Subversion / Mercurial / Git / etc gibt es wahrscheinlich gute Möglichkeiten, den Verlauf der realen Quelldateien an beiden Stellen miteinander zu verknüpfen.

Anscheinend gibt es auf beiden Seiten sehr starke und überzeugende Meinungen. Ich würde empfehlen, alle Antworten mit den höchsten Stimmen zu lesen und dann zu entscheiden, welche Argumente für Ihren speziellen Fall gelten.

UPDATE: Ich habe diese Frage gestellt, da ich wirklich geglaubt habe, dass es eine endgültige Antwort gibt. Wenn ich mir alle Antworten anschaue, kann ich mit hoher Sicherheit sagen, dass es keine solche Antwort gibt. Die Entscheidung sollte auf der Grundlage von mehr als einem Parameter getroffen werden. Das Lesen der anderen Antworten könnte eine sehr gute Richtlinie für die Arten von Fragen sein, die Sie sich stellen sollten, wenn Sie sich für dieses Problem entscheiden müssen.