Sollte ich store generierten code in die source-control
Dies ist eine Diskussion nehme ich ein Teil in. Ich würde gerne mehr Meinungen und Sichtweisen.
Wir haben einige Klassen, die generiert werden, im build-Zeit zu behandeln, DB-Operationen (in Diesem konkreten Fall, mit Infraschall, aber ich glaube nicht, es ist sehr wichtig für die Frage). Die generation wird als pre-build-step in Visual Studio. Also jedes mal, wenn ein Entwickler (oder die offizielle build-Prozess) wird ein zu bauen, sind diese Klassen generiert und anschließend kompiliert das Projekt.
Nun einige Leute behaupten, dass diese Klassen gespeichert in source control könnte zu Verwirrung führen, im Falle der code, den Sie erhalten, nicht mit dem übereinstimmt, was gewesen wäre, erzeugt in Ihrer eigenen Umgebung.
Ich würde gerne eine Möglichkeit haben, zurück verfolgen die Geschichte des Kodex, auch wenn es in der Regel als eine Art Blackbox behandelt.
Irgendwelche Argumente oder Gegenargumente?
UPDATE: ich habe diese Frage gestellt, da ich wirklich geglaubt, dass es eine definitive Antwort. Blick auf all die Antworten, ich könnte sagen, mit hoher Sicherheit, dass es keine solche Antwort. Sollte die Entscheidung auf der Grundlage von mehr als einem parameter. Lesen Sie die Antworten unten könnte ein sehr guter Leitfaden über die Arten von Fragen, die Sie sollten sich Fragen, wenn Sie, dass Sie entscheiden, zu diesem Thema.
Werde ich nicht wählen Sie eine akzeptierte Antwort an dieser Stelle für den oben genannten Gründen.
- Sie können daran interessiert sein, eine ähnliche Frage: stackoverflow.com/questions/739391/...
- Ich möchte sagen, im Falle von Infraschall -, könnte es interessant sein, zu halten, in der Quellcodeverwaltung als ein Weg, um auch (einigen) Datenbank-änderungen leicht in den Fall, Sie haben keine andere Möglichkeit der Verfolgung der Geschichte Ihres Datenbank.
- In meinem denken, das Hauptproblem ist, dass verschiedene Entwickler nicht das gleiche Ergebnis bei der Generierung der Klassen. Die config für die Erzeugung überprüft werden soll, und geben konsequent baut in allen Entwickler-Umgebungen.
- Weiß nicht, wie dies zu tun, aber ich denke, diese Frage sollte jetzt geschlossen werden, da es zu öffnen, um Meinung und Diskussion ohne Bezug fest auf bestimmte source-control-Systeme oder bestimmte Arten von Dateien erzeugt.
- Dies ist eine große Frage, aber es ist auch Meinung-basiert, SO dass, wie angezeigt, durch die mehrere widersprüchliche Antworten, und die OP ' s eigenen Kommentar zu diesem Effekt.
Du musst angemeldet sein, um einen Kommentar abzugeben.
Speichern Sie es in der source-control ist mehr ärger als es Wert ist.
Müssen Sie eine commit jedes mal, wenn Sie eine bauen, für die es einen Wert.
In der Regel verlassen wir generierten code( idl, jaxb Zeug, etc) ausserhalb der source-control, wo ich arbeite und es ist nie ein problem gewesen,
Jedes mal, wenn ich will, um zu zeigen, änderungen an einem source tree auf meiner eigenen repo, die alle die "generierte Dateien" wird angezeigt, wie haben sich verändert und müssen die Begehung.
Ich würde lieber eine saubere Liste von Modifikationen, die nur echte updates, die durchgeführt wurden, und nicht automatisch generiert wird, ändert.
Lassen Sie Sie aus, und dann nach ein zu bauen, fügen Sie eine 'ignorieren' auf jede der erzeugten Dateien.
Legen Sie es in source-code-control. Der Vorteil ist, dass die Geschichte alles, was Sie schreiben verfügbar für zukünftige Entwickler überwiegt der kleine Schmerz, der gelegentlich Wiederaufbau nach einem sync.
Sieh es mal so: rufen Sie Ihre Objekt-Dateien in die its-source-control? Generierte Quelldateien build-Artefakte wie object-Dateien, libraries und ausführbare Dateien. Sie sollten behandelt werden. Die meisten würden argumentieren, dass Sie sollten nicht überprüfen erzeugten Objekt-Dateien und ausführbare Dateien in die its-source-control. Die gleichen Argumente gelten für generierte Quelle.
Wenn Sie brauchen, um sich an der historischen version einer generierten Datei können Sie synchronisieren, um die historische version Ihrer Quellen und neu erstellen.
Überprüfung der generierten Dateien jeglicher Art in die Quellcodeverwaltung, ist Analog zu der Datenbank Denormalisierung. Es gibt gelegentlich Gründe, dies zu tun (in der Regel für die Leistung), aber dies sollte nur getan werden, mit großer Sorgfalt, denn es wird viel schwieriger zu pflegen Korrektheit und Konsistenz sobald die Daten denormalisierten.
Ich würde sagen, dass Sie sollten vermeiden Sie alle generierten code (oder andere Artefakte) zur Quellcodeverwaltung. Wenn der generierte code ist das gleiche für die gegebene Eingabe dann könnte man einfach mal die Versionen, die Sie wollen, zu vergleichen und generieren Sie den code für den Vergleich.
Nenne ich das DRY-Prinzip. Wenn Sie bereits über die "Quell-Dateien" in das repository, die verwendet werden zum generieren dieser code-Dateien zu erstellen, gibt es keine Notwendigkeit, den gleichen code verpflichtet "zweimal".
Auch, Sie könnten sich abwenden, einige Probleme dieser Art, wenn zum Beispiel der code-generation bricht irgendwann.
Ich wirklich don ' T denke, Sie sollten überprüfen Sie Sie in.
Sicherlich keine änderung im generierten code wird entweder gehen, um Lärm - änderungen zwischen Umgebungen oder Veränderungen als Folge von etwas anderem - z.B. eine Veränderung in deiner DB. Wenn Sie Ihre DB-Erstellung Skripte (oder andere Abhängigkeiten) sind in der Quellcodeverwaltung dann, warum tun Sie müssen die generierten Skripte?
Nein, aus drei Gründen.
Source code ist alles, was notwendig und ausreichend, um die Wiedergabe einer Momentaufnahme Ihrer Anwendung, wie von einigen aktuellen oder früheren Zeitpunkt - nichts mehr und nichts weniger. Teil dessen, was dies bedeutet, ist, dass jemand, der für alles verantwortlich eingecheckt. In der Regel ich bin glücklich, die Verantwortung für den code, den ich Schreibe, aber nicht den code, der generiert als Folge von dem, was ich Schreibe.
Ich nicht will, dass jemand versucht sein, eine Verknüpfung bauen, die aus primären Quellen durch die Verwendung von intermediate-code, der möglicherweise oder möglicherweise nicht den aktuellen (und vor allem, dass ich nicht wollen, Verantwortung dafür zu übernehmen.) Und nicht, es ist zu verlockend für einige Menschen geraten in einen sinnlosen Prozess zu Debuggen Konflikte in intermediate code basieren auf teilweise baut.
Sobald es in der source-control, ich übernehme die Verantwortung für eine. es wird dort b. es werden aktuelle und c. es wird zuverlässig integrierbar mit sonst alles drin. Das beinhaltet das entfernen es, wenn ich Sie nicht mehr verwenden. Die weniger Verantwortung, desto besser.
Die Allgemeine Regel ist keine, aber wenn es Zeit braucht, um den code zu generieren (weil der DB-Zugriff, web services, etc.) dann möchten Sie vielleicht zu speichern, eine zwischengespeicherte version der source-control und speichern Sie alle den Schmerz.
Ihre Werkzeuge auch müssen sich bewusst sein, von dieser und Griff den Check-out aus der source-control, wenn nötig, zu viele tools entscheiden, zum check out aus der source-control, ohne Grund.
Ein gutes Werkzeug, werden die zwischengespeicherten version, ohne es zu berühren (oder die Modifizierung der Zeit Schritte auf der Datei).
Werden Sie brauchen, um große Warnung im inneren des generierten Codes für die Menschen, nicht die Datei ändern, wird eine Warnung an der Spitze ist nicht genug, müssen Sie wiederholen es jeden Dutzend Zeilen.
Wir nicht speichern Sie die erstellte DB-code: da es erzeugt wird, können Sie es am Willen zu jeder bestimmten version von der source-Dateien. Speichern wie es sein würde, die Speicherung von bytecode oder so.
Nun, Sie müssen sicherstellen, dass der code-generator verwendet, die bei einer bestimmten version verfügbar ist! Neuere Versionen erzeugen kann, die unterschiedlichen code...
Lassen Sie es aus.
Wenn Sie Check-in generierten Dateien dann machst du etwas falsch. Was ist falsch unterscheiden kann, könnte es sein, dass Ihr build-Prozess ist ineffizient, oder etwas anderes, aber ich kann es nicht sehen immer eine gute Idee. Die Geschichte soll verbunden werden mit der Quell-Dateien, die nicht für die generierte.
Es erzeugt nur Kopfschmerzen für Menschen, die dann am Ende versuchen, um Unterschiede zu beheben, suchen Sie die Dateien, die nicht mehr erzeugt durch das erstellen und löschen Sie Sie anschließend, etc.
Einer Welt der Schmerzen erwartet diejenigen, die check-in generierten Dateien!
Gibt es einen besonderen Fall, wo Sie wollen, schauen Sie in die generierten Dateien: wenn Sie benötigen, um auf Systeme, in denen die Werkzeuge verwendet, um zu erzeugen, die andere Dateien nicht zur Verfügung. Das klassische Beispiel dafür, und ich arbeite mit Lex und Yacc-code. Denn wir entwickeln ein runtime-system, zu bauen und laufen auf einer Vielzahl von Plattformen und Architekturen, setzen wir können nur auf der target-Systeme haben die C-und C++ - Compiler, nicht die notwendigen Werkzeuge zu generieren, die sind das sogenannte Lexing/parsing-code für das interface-definition-übersetzer. Also, wenn wir ändern unsere Grammatiken, prüfen wir in den generierten code zu analysieren.
Ankunft ein wenig spät ... trotzdem ...
Würdet Ihr compiler die Zwischendatei in die source version control ?
Im Fall der code-Generierung, durch die definition der source-code ist die Eingabe des Generators, während der erzeugte code kann als ein Zwischenformat zwischen der "echten" Quelle und den integrierten Anwendung.
Also ich würde sagen: don ' T put generiert code unter Versionskontrolle steht, aber der generator und die Eingabe.
Konkret arbeite ich mit einem code-generator schrieb ich: ich hatte nie zur Aufrechterhaltung der generierte source-code unter Versionskontrolle steht. Ich würde sogar sagen, dass da der generator erreicht eine bestimmte Reife, die ich nicht beachten, der Inhalt von generierten code, obwohl der input (zum Beispiel Modell-Beschreibung) geändert.
In einige Projekte, die ich hinzufügen generierten code auf source-control, aber es hängt wirklich. Meine einfache Regel ist, wenn der generierte code ist ein wesentlicher Bestandteil der compiler dann werde ich nicht hinzufügen. Wenn der generierte code aus einem externen tool, wie z.B. SubSonic, in diesem Fall, dann würde ich hinzufügen, wenn das Datenquellen-Steuerelement. Wenn Sie in regelmäßigen Abständen aktualisieren Sie die Komponente, dann möchte ich wissen, die änderungen in den generierten source-falls Fehler oder Probleme auftreten.
Soweit generierten code müssen überprüft werden, eine worst-case-Szenario ist manuell differenzierende Dateien und das wiederherstellen der Dateien, wenn nötig. Wenn Sie mit svn, können Sie ein pre-commit hook im svn zu leugnen, Begehen, wenn die Datei hat sich nicht wirklich geändert.
Es hängt wirklich. Letztendlich ist das Ziel, um in der Lage zu reproduzieren, was Sie hatten, wenn es sein muss. Wenn Sie sind in der Lage, sich zu regenerieren Sie Ihre Binärdateien genau, es gibt keine Notwendigkeit, Sie zu speichern. aber Sie müssen Bedenken, dass, um neu zu erstellen Sie Ihre Sachen Sie werden wahrscheinlich brauchen deine genaue Konfiguration, die Sie Tat es mit in den ersten Platz, und das heißt nicht nur Ihre source-code, aber auch das build environment, IDE, vielleicht auch andere Bibliotheken, Generatoren oder Sachen, in genau der Konfiguration (Versionen), die Sie verwendet haben.
Habe ich Probleme in Projekten wurden aktualisiert wir unsere build-Umgebung auf neuere Versionen oder sogar zu einem anderen Anbieter, wo wir waren nicht in der Lage, neu zu erstellen die genaue Binärdateien, die wir vorher hatten. Dies ist eine echte Schmerzen, wenn die Binärdateien werden deplyed sind abhängig von einer Art von hash, vor allem in der gesicherten Umgebung, und die neu erstellte Dateien irgendwie unterscheiden sich, weil der compiler upgrades oder was auch immer.
So, würde Sie store generierten code: ich würde sagen Nein. Die Binärdateien oder deliverables, die freigegeben werden, einschließlich der Werkzeuge, die Sie reproduziert, Ihnen mit würde ich store. Und dann gibt es keine Notwendigkeit, speichern Sie diese in der source-control, machen Sie einfach eine gute Sicherung der Dateien.
Den job von configuration management (Versionen-Kontrolle ist nur ein Teil) ist in der Lage sein, Folgendes zu tun:
Die erste sorgt dafür, dass, wenn Sie sagen, der Kunde oder Endbenutzer "den Fehler, den Sie in der vergangenen Woche berichteten, ist fixiert, und die neue Funktion wurde Hinzugefügt," Sie kommen nicht wieder zwei Stunden später und sagen "Nein, es hat nicht". Es macht auch sicher, dass Sie nicht sagen: "Warum ist es zu tun X? Wir haben nie gefragt, für X".
Die zweite bedeutet, dass, wenn der Kunde oder Endbenutzer meldet einen bug in einer version, die Sie ausgestellt vor einem Jahr, Sie können gehen Sie zurück zu dieser version, reproduzieren Sie den Fehler, beheben Sie es, und beweisen, dass es Ihr fix beseitigt den Fehler, anstatt eine Störung der compiler und andere Updates.
Dies bedeutet, dass Ihr compiler, Bibliotheken etc. müssen auch ein Teil von CM.
So, jetzt Ihre Frage zu beantworten: wenn Sie tun können, alle oben genannten, dann brauchen Sie nicht zu hinterlegen, um eine zwischendarstellung, denn Sie werden garantiert, um die gleiche Antwort sowieso. Wenn Sie nicht alle der oben genannten, dann sind alle Wetten ab, weil Sie nie garantieren können, um die gleiche Sache zweimal und die gleiche Antwort erhalten. So könnten Sie auch alle Ihre .o Dateien unter Versionskontrolle sowie.
Die richtige Antwort ist "Es Hängt". Es hängt davon ab, was der Kunde braucht.
Wenn Sie ein Rollback-code zu einer bestimmten Version und stehen für alle externen audit ist ohne ihn, dann bist du noch nicht auf festem Boden. Als dev ist, dann müssen wir nicht nur 'Rauschen', Schmerz und Speicherplatz, aber die Tatsache, dass wir mit der Aufgabe betraut sind, die Rolle der Generierung von geistigem Eigentum, und es kann rechtliche Konsequenzen. Wären Sie in der Lage, zu einem Richter beweisen, dass Sie in der Lage, sich zu regenerieren einer web-Seite genau die Weise, die ein Kunde sah es vor zwei Jahren?
Ich bin nicht darauf hindeutet, Sie speichern oder nicht speichern-gen würde-Dateien, je nachdem, welcher Weg Sie sich entscheiden, wenn Sie nicht mit den Fachexperten der Entscheidung sind Sie wahrscheinlich falsch.
Meine zwei Cent.
Es gibt gute Argumente für und gegen die hier präsentiert wird.
Für das Protokoll, ich Baue die T4-generation-Systems in Visual Studio und unser Standard-out-of-the-box-option generierte code eingecheckt werden. Haben Sie ein bisschen härter arbeiten, wenn Sie es vorziehen, nicht zum check-in.
Ist für mich der Schlüssel überlegung ist die diff-Ausgabe generiert, wenn entweder der Eingang oder der generator selbst aktualisiert.
Wenn Sie nicht über Ihre Ausgabe eingecheckt, dann haben Sie to nehmen Sie eine Kopie aller generierten code vor dem Upgrade einen generator oder ändern Eingabe, um vergleichen zu können, die mit der Ausgabe der neuen version. Ich denke, dies ist ein ziemlich langwieriger Prozess, aber mit überprüft, in der Ausgabe, es ist einfach eine Frage der diff-die neue Ausgabe mit dem Archiv.
Zu diesem Zeitpunkt ist es vernünftig, zu Fragen, "Warum kümmert man sich um änderungen im generierten code?" (Vor allem im Vergleich zu object-code.)
Ich glaube, es gibt ein paar wichtige Gründe, die nach unten kommen, um den aktuellen Stand der Technik eher als eine inhärente problem.
Herstellung von handgeschriebenen code, dass die Maschen eng mit dem generierten code. Das ist nicht der Fall auf der ganzen mit obj-Dateien in diesen Tagen. Wenn der generierte code verändert, es ist leider ganz oft der Fall, dass einige handgeschriebene code ändern muss um zu passen. Leute oft gar nicht beobachten einen hohen Grad an Rückwärtskompatibilität mit den Erweiterungspunkten im generierten code.
Generierten code einfach ändert sein Verhalten. Sie würde nicht dulden, das von einem compiler, aber in fairness, ein application-level-code-generator ist für eine andere Bereich der problem mit einer breiteren Palette von akzeptablen Lösungen. Es ist wichtig, zu sehen, wenn Annahmen über Sie gemacht, frühere Verhalten, sind jetzt gebrochen.
Du einfach nicht 100% Vertrauen, die Ausgabe des Generators von release zu release. Es gibt eine Menge von Wert zu sein, hatte von generator-tools, selbst wenn Sie nicht gebaut und gepflegt werden, mit der strenge Ihrer compiler-Hersteller. Version 1.0 gewesen sein könnte, absolut stabil, für Ihre Anwendung, aber vielleicht 1.1 hat ein paar Pannen, für Ihren Fall jetzt. Alternativ ändern Sie die Eingabewerte und zu finden, dass Sie exercisig ein neues Stück von dem generator, den Sie nicht verwendet hatten, bevor Sie - möglicherweise erhalten Sie von den Ergebnissen überrascht.
Im wesentlichen alle diese Dinge nach unten kommen, um tool-maturity - die meisten business-app code-Generatoren sind nicht annähernd auf dem Niveau, dass Compiler oder auch lex/yacc-level-Werkzeuge wurden für die Jahre.
Beide Seiten haben eine gültige und vernünftige argument, und es ist schwierig zu erklären, auf etwas gemeinsames. Version Control Systems (VCSs) Spuren der Dateien
die Entwickler hineingesteckt haben, und die Annahme, dass die Dateien in VCS sind handgefertigt von Entwicklern und Entwicklern, die daran interessiert sind, die Geschichte
und Sie wechseln zwischen jede änderung der Dateien. Diese Annahme ausgleichen, die zwei Konzepte, "ich möchte um diese Datei zu erhalten, wenn ich Kasse." und "ich bin
interessiert die Veränderung dieser Datei."
Nun, die Argumente von beiden Seiten werden könnte, formulieren Sie so:
Glücklicherweise scheint es, dass die beiden Anforderungen sind nicht in Konflikt grundlegend. Mit einigen Erweiterung der aktuellen VCSs, sollte es möglich sein, zu haben
beide. In anderen Worten, es ist eine falsche dilemma. Wenn wir überlegen eine Weile, es ist nicht schwer zu erkennen, dass das problem ergibt sich aus der Annahme VCSs halten. VCSs
unterscheiden sollte die Dateien, die sind von hand gefertigt, die von Entwicklern, von Dateien, die nicht hand in Handarbeit gemacht von den Entwicklern, aber gerade passiert zu sein im inneren
dieses VCS. Für die erste Kategorie der Dateien, die wir als Quell-Dateien (code) Regel, VCSs getan haben tolle Arbeit jetzt. Für die Letztgenannte Kategorie, VCSs haben
hatte nicht solches Konzept noch nicht, soweit ich weiß.
Zusammenfassung
Nehme ich git als ein Beispiel, um zu illustrieren, was ich meine.
git status
sollten nicht zeigen generierten Dateien standardmäßig.git commit
sollten die generierten Dateien als snapshot.git diff
sollten nicht zeigen generierten Dateien standardmäßig.PS
Git-hooks verwendet werden könnte, als ein workaround, aber es wäre toll, wenn git unterstützt es nativ.
gitignore
erfüllt nicht unsere Forderung, für ignoriertDateien gehen nicht in VCSs.
enter code here
Ich würde behaupten für. Wenn Sie einen continuous integration-Prozess, der prüft sich den code, und ändert die build-Nummer, baut die software und dann testet, dann ist es einfacher und einfacher, einfach diesen code als Teil Ihres repository.
Darüber hinaus ist es Bestandteil jeder "Momentaufnahme", die Sie von Ihrem software-repository. Wenn es ein Teil der software, dann sollte es Teil der repository.
Ich würde sagen, ja Sie wollen es unter Kontrolle der Quellcodeverwaltung. Von einem Konfigurations-management-Standpunkt aus ALLES, was, die verwendet wird, um zu produzieren, eine software zu bauen, muss so gesteuert werden, dass es wiederhergestellt werden können. Ich verstehe, dass der generierte code kann leicht nachempfunden werden, aber ein argument kann gemacht werden, dass es nicht die gleiche, da die Datums - /Zeitstempel wird der Unterschied zwischen den beiden aufbaut. In einigen Bereichen wie Regierung, Sie erfordern eine Menge Zeit, dies ist, was getan wird.
Im Allgemeinen, generierter code muss nicht gespeichert werden, in der source-control, denn die revision der Geschichte dieser code kann zurückverfolgt werden, durch die revision der Geschichte des code, der Sie erzeugt!
Jedoch, es klingt der OP ist es mit dem generierten code der data access layer der Anwendung, anstatt manuell zu schreiben. In diesem Fall, ich würde den build-Prozess und übernehmen die code-source-control, weil es ein wichtiger Bestandteil der runtime-code. Dies entfernt auch die Abhängigkeit auf der code generation tool aus dem build-Prozess im Fall, dass die Entwickler benötigen, verwenden andere version des Tools, die für verschiedene Branchen.
Es scheint, dass der code muss nur erzeugt werden, wenn statt jeder bauen. Wenn ein Entwickler benötigt, um hinzufügen/entfernen/ändern, wie ein Objekt auf die Datenbank zugreift, sollte der code erneut generiert werden, nur wie machen manuelle änderungen. Dies beschleunigt den build-Prozess ermöglicht die manuelle Optimierungen vorgenommen werden, um die data-access-Schicht, und die Geschichte der data access layer wird beibehalten, in einer einfachen Art und Weise.
Ich (mit bedauern) wind-up, eine Menge von abgeleiteten Quellen, die unter Kontrolle der Quellcodeverwaltung, weil ich aus der Ferne arbeiten mit Menschen, die entweder nicht belästigt werden, ein geeignetes build-Umgebung oder die don ' T haben die Fähigkeiten, um es so einrichten, dass die abgeleiteten Quellen gebaut werden, genau das richtige. (Und wenn es um die Gnu-autotools, ich bin eine von den Menschen selbst! Ich kann nicht arbeiten mit drei verschiedenen Systemen, von denen jeder arbeitet mit einer anderen version von autotools—und nur diese version.)
Diese Art von Schwierigkeit ist wahrscheinlich für mehr Teilzeit -, Freiwilligen -, open-source-Projekten als bezahlte Projekte, in denen die person, die die Rechnungen bezahlen können, bestehen Sie auf eine einheitliche build-Umgebung.
Wenn Sie dies tun, sind Sie im Grunde Begehen ein Gebäude der abgeleiteten Dateien nur an einem Ort oder nur an ordnungsgemäß konfiguriert Seiten. Die Makefiles (oder was auch immer) eingerichtet werden soll, um zu bemerken, wo Sie ausgeführt werden und sollten sich weigern, der re-Quellen ableiten, es sei denn, Sie wissen, dass Sie eine sichere Website bauen.
Unbedingt den generierten code in die source-control, aus vielen Gründen. Ich bin das wiederholen, was viele Leute schon gesagt haben, aber einige Gründe, warum ich es tun würde, sind
CodeCompileUnit
in eine kanonische Reihenfolge.Ich würde der generierten Dateien beibehalten, aus von einem source-tree, aber es in einen separaten build-tree.
z.B. workflow ist
Wahrscheinlich gibt es gute Möglichkeiten in Subversion/Mercurial/Git/etc. zu binden, die Geschichte der realen Quelle die Dateien in beide Orte zusammen.
Wenn es Teil der source-code sollte es dann in die source-control-unabhängig davon, wer oder was Sie erzeugt. Sie möchten, dass Ihre Quell-Steuerelement zum spiegeln den aktuellen Zustand Ihres Systems, ohne sich zu regenerieren es.
Aussieht, gibt es sehr starke und überzeugende Meinungen auf beiden Seiten. Ich würde empfehlen, das Lesen alle top gestimmt Antworten, und dann entscheiden, welche Argumente gelten für Ihren konkreten Fall.
UPDATE: ich fragte diese Frage, da ich wirklich geglaubt, dass es eine definitive Antwort. Blick auf all die Antworten, ich könnte sagen, mit hoher Sicherheit, dass es keine solche Antwort. Sollte die Entscheidung auf der Grundlage von mehr als einem parameter. Das Lesen der anderen Antworten konnte, bieten eine sehr gute Richtschnur, um die Arten von Fragen, die Sie sollten sich Fragen, wenn Sie, dass Sie entscheiden, zu diesem Thema.