Aufruf für Einsicht: Revisionskontrolle und Binärdateien

Ich glaube, dass Binärdateien nicht zusammen mit ihrem Quellcode in der Versionskontrolle gespeichert werden sollten.

Nachteile:

• Es fördert schlechte Baupraktiken in großen Projekten. Die beste Vorgehensweise besteht darin, Ihren vollständigen Build vollständig zu automatisieren (nicht nur die Quellkompilierung, sondern auch das Ausführen automatisierter Tests, das Verpacken von Dokumentation, das Generieren eines Setups usw.). Durch die Übergabe von Binärdateien können Sie dies ignorieren: "Führen Sie den Build für die geänderten Teile einfach manuell aus".
• langsamere Updates und Commits
• muss jedes Mal, wenn Sie nach der Erstellung eines Builds
aktualisieren, Konflikte mit Binärdateien beheben
• Commits, die Quellcode ändern, aber nicht die entsprechenden Binärdateien, führen zu Verwirrung unter den Entwicklern. Wie stellen Sie fest, dass ein Missverhältnis vorliegt?
• svn update aktualisiert den Zeitstempel Ihrer Binaries und verwechselt Ihre Build-Tools, die fälschlicherweise denken, dass die Binaries neuer sind als Ihr Quellcode.
• es benötigt mehr Speicherplatz im Repository. (Dies kann je nach Projekt vernachlässigbar sein.)

Im Allgemeinen sollten Sie meiner Meinung nach vermeiden, etwas zu begehen, das auf deterministische Weise automatisch von anderen versionierten Ressourcen generiert wird. Keine Redundanz - & gt; keine Möglichkeit für Inkonsistenzen.

Verwenden Sie stattdessen einen Continuous Integration Server, um die Commits automatisch neu zu erstellen (und die Tests auszuführen). Lassen Sie diesen Build-Server die Binärdateien irgendwo (außerhalb von SVN) veröffentlichen, falls erforderlich, wie einen freigegebenen Ordner im Netzwerk.

Ich würde empfehlen, keine Binärdateien mit DVCS zu mischen (wie git und Mercurial). Der Hauptgrund dafür ist: Alle nicht zusammenführbaren Dateien sind ein Problem für DVCS. DVCS setzt grundsätzlich auf qualitativ hochwertige Zusammenführungen von Dateien, damit das DVCS-Konzept funktioniert (siehe diese Diskussion über Binärdateien in Git ).

Ich stimme zu, dass Binärdateien gespeichert werden sollten. Sie sollten jedoch wahrscheinlich an einem anderen Ort als Ihrem Versionskontrollsystem gespeichert werden. Vielleicht ein Server mit kontrolliertem Schreibzugriff. Vielleicht ein getrenntes zentralisiertes VCS-Repository, z. B. Subversion, wenn Sie den gesamten Verlauf beibehalten möchten.

Um zu vermeiden, dass eine solche Trennung "peinlich und fehleranfällig" ist, wie Sie sagen, versuchen Sie, sie so weit wie möglich zu automatisieren. Erstellen Sie eine automatisierte Build-Prozedur, die sicherstellt, dass die Quelle versioniert / markiert ist, eine vollständige Erstellung durchführt und die Ausgabe (korrekt benannt, versioniert, markiert usw.) in den angegebenen Speicher legt.