Binärdateien in der Quellcodeverwaltung

30

Bei der Entwicklung für eingebettete Geräte und andere ungewöhnliche Welten wird Ihr Erstellungsprozess höchstwahrscheinlich mehrere proprietäre Binärdateien enthalten, die sehr spezifische Versionen davon verwenden. Die Frage ist also, ob sie Teil Ihrer Quellcodeverwaltung sind. In meinem Büro gilt die Regel, dass das Auschecken aus der Quellcodeverwaltung alles beinhaltet, was Sie zum Kompilieren des Codes benötigen. Dies hat zu ernsthaften Argumenten geführt.

Das Hauptargument, das ich dagegen sehe, ist das Aufblähen der Quellcodeverwaltungs-DB, das Fehlen unterschiedlicher Binärdateien ( siehe vorherige Fragen zu diesem Thema) . Dies steht im Widerspruch zu der Möglichkeit, Dateien auszuchecken, zu erstellen, zu wissen, dass Sie die genaue Umgebung haben, die der vorherige Entwickler beabsichtigt hat, und ohne die entsprechenden Dateien zu durchsuchen (mit bestimmten Versionen nicht weniger!).

Daniel Goldberg
quelle
3
Alternativ können Sie ein bash / python / perl / bat-Skript schreiben, um den Quellcode auszuchecken und alle anderen abhängigen Komponenten in einem einzigen Schritt herunterzuladen. Ich würde jedoch trotzdem empfehlen, Binärdateien in Ihre Versionskontrolle einzuchecken, nur um Revisionen zu behalten. Die einzigen Dateien, die nicht in das Repository eingecheckt werden sollten, sind Dateien, die leicht aus versionskontrollierten Dateien wiederhergestellt werden können. Speicherplatz ist billig und sollte keine große Rolle spielen.
Lie Ryan

Antworten:

28

Die Idee von VERSION CONTROL (falsche Bezeichnung: Quellcodeverwaltung) besteht darin, einen Rollback durch den Verlauf zu ermöglichen, die Auswirkungen von Änderungen wiederherzustellen, Änderungen anzuzeigen und zu erklären, warum sie vorgenommen wurden. Dies ist eine Reihe von Anforderungen, von denen einige Binärdinge benötigen, andere nicht.

Beispiel: Für die Arbeit mit eingebetteter Firmware verfügen Sie normalerweise über eine vollständige Toolchain: entweder einen proprietären Compiler, der viel Geld kostet, oder eine Version von gcc. Um die ausführbare Versanddatei zu erhalten, benötigen Sie die Toolchain sowie die Quelle.

Das Einchecken von Toolchains in die Versionskontrolle ist mühsam, die Hilfsprogramme sind (wenn überhaupt) schrecklich, aber es gibt keine Alternative. Wenn Sie möchten, dass die Toolchain für den Benutzer erhalten bleibt, der in 5 Jahren Ihren Code überprüft, um herauszufinden, was er tut, haben Sie keine andere Wahl: Sie MÜSSEN die Toolchain auch unter Versionskontrolle haben.

Ich habe im Laufe der Jahre herausgefunden, dass die einfachste Methode, dies zu tun, darin besteht, ein ZIP- oder ISO-Image der Installations-CD zu erstellen und dieses einzuchecken. Der Check-in-Kommentar muss die Versionsnummer des Herstellers der Toolchain sein. Wenn gcc oder ähnliches, bündeln Sie alles, was Sie verwenden, in einer großen ZIP-Datei und tun Sie dasselbe.

Der extremste Fall, den ich je gemacht habe, ist Windows XP Embedded, wo die "Toolchain" eine laufende Windows XP-VM ist, die (damals) SQL Server und einen Stapel Konfigurationsdateien sowie Hunderte und Hunderte von Patch-Dateien enthielt. Die Installation und Aktualisierung des gesamten Grundstücks dauerte ca. 2-3 Tage. Um dies für die Nachwelt zu erhalten, musste die GESAMTE VM in die Versionskontrolle eingecheckt werden. Da die virtuelle Festplatte aus ungefähr 6 x 2 GB-Images bestand, lief sie tatsächlich recht gut. Hört sich übertrieben an, aber es hat der Person, die nach mir kam und es benutzen musste, das Leben sehr erleichtert - 5 Jahre später.

Zusammenfassung: Die Versionskontrolle ist ein Tool. Verwenden Sie es, um effektiv zu sein, lassen Sie sich nicht von Dingen wie der Bedeutung von Wörtern aus der Ruhe bringen und nennen Sie es nicht "Quellcodeverwaltung", weil es größer ist.

schnell_nun
quelle
1
Und wann muss die VM auf 12 GB aktualisiert werden? Selbst wenn Sie gute binäre Unterschiede haben, sprechen Sie immer noch von einem Repo von
10
3
Nun, nein. Wenn Sie VMWare verwenden, können Sie Festplatten-Snapshots verwenden. Diese speichern das ursprüngliche Basis-Disk-Image und fügen neue Dateien hinzu, die nur die recht kleinen Deltas enthalten. Sie müssen nur daran denken, die neu erstellten Dateien einzuchecken. Zuletzt habe ich mir dies angeschaut, ein Update über 250K - Hühnerfutter hinzugefügt. Außerdem ist es sinnlos, sich Gedanken über die Repo-Größe zu machen - die Festplatte ist billig.
quick_now
Was ist, wenn Ihre Embedded - Toolkette hängt von einer Netzwerk - Lizenz :)
Dan
18

Neal Ford argumentiert in den produktiven Programmierern , dass Sie sollte Binärdateien in der Quellcodeverwaltung halten:

Warum Binärdateien behalten? Projekte sind heute auf eine Vielzahl externer Tools und Bibliotheken angewiesen. Angenommen, Sie verwenden eines der gängigen Protokollierungsframeworks (wie Log4J oder Log4Net). Wenn Sie die Binärdateien für diese Protokollbibliothek nicht als Teil Ihres Erstellungsprozesses erstellen, sollten Sie sie in der Versionskontrolle belassen. Auf diese Weise können Sie Ihre Software auch dann weiterentwickeln, wenn das betreffende Framework oder die betreffende Bibliothek nicht mehr zur Verfügung steht (oder mit größerer Wahrscheinlichkeit eine grundlegende Änderung in einer neuen Version einführt). Behalten Sie immer das gesamte Universum bei, das zum Erstellen Ihrer Software in der Versionskontrolle erforderlich ist(Abzüglich des Betriebssystems, und selbst das ist mit Virtualisierung möglich; siehe „Verwenden von Virtualisierung“ weiter unten in diesem Kapitel). Sie können die Beibehaltung von Binärdateien optimieren, indem Sie diese sowohl in der Versionskontrolle als auch auf einem freigegebenen Netzwerklaufwerk beibehalten. Auf diese Weise müssen Sie sich nicht stündlich mit ihnen befassen, sondern sie werden gespeichert, falls Sie ein Jahr später etwas neu aufbauen müssen. Sie wissen nie, ob Sie etwas neu aufbauen müssen. Sie bauen es, bis es funktioniert, und vergessen es dann. Es ist panisch, wenn man merkt, dass man etwas von vor zwei Jahren neu aufbauen muss und nicht alle Teile hat.

Ich konnte nicht mehr zustimmen; Während dies das VCS möglicherweise für eine Aufgabe untergräbt, für die es nicht entwickelt wurde (Beibehalten von Binärdateien), überwiegen meiner Meinung nach die Vorteile die potenziellen Nachteile. Wie der Autor jedoch später feststellt, ist es unter Umständen nicht praktikabel, die Binärdateien in VCS beizubehalten. Daher sollten andere Optionen in Betracht gezogen werden, z. B. die Speicherung auf einem zugeordneten Netzlaufwerk.

Wenn die Binärdateien nicht zu groß sind, würde ich sie definitiv in VCS behalten. Dies scheint in Ihrem Fall sogar noch zutreffender zu sein, da die Binärdateien wahrscheinlich klein sind und Sie mit sehr spezifischen Versionen arbeiten. Sie können aus verschiedenen Gründen auch schwer zu finden sein (die Autoren haben ihre Website geschlossen oder die von Ihnen benötigte Version wird nicht mehr zum Download angeboten). Obwohl unwahrscheinlich, wissen Sie nie, was in ein paar Jahren passieren wird.

Ich wünschte, ich hätte dieses Buch vor ein paar Jahren gelesen, als ich an einem Spiel mit einer Grafikbibliothek (die eine DLL-Datei war) arbeitete. Ich unterbrach die Entwicklung für eine Weile, und als ich fortfahren wollte, konnte ich die DLL nicht wieder finden, weil das Projekt starb.

Mihai Rotaru
quelle
2
Ja, das passiert allzu oft. Ich habe ein Hobbyprojekt, bei dem ich mich auf einen Scanner-Generator verlasse, der vor 3-4 Jahren von seinem Autor aufgegeben wurde. Zum Glück war es immer unter Versionskontrolle.
Christian Klauser
9

Grundsätzlich schätze ich das Camp "Prüfen Sie alles, was Sie brauchen, um in die Quellcodeverwaltung zu integrieren", aber das Abhängigkeitsmanagement hat sich in den letzten Jahren mit Tools wie Maven, Ivy und NuGet erheblich weiterentwickelt.

Außerdem finde ich in der Praxis das Einchecken von Binärdateien, um eine Reihe von unangenehmen Nebenwirkungen hervorzurufen. Git / Mercurial sind zum Beispiel nicht wirklich darauf abgestimmt, und Subversion und Perforce können Sie verrückt machen, wenn Sie Zweige zusammenführen, die Binärdateien enthalten.

Mit einer Abhängigkeitsverwaltungslösung geben Sie in einer quellgesteuerten Datei in Ihrem Projekt an, von welchen Paketnamen und von welchen Versionen Ihr Projekt abhängt. Mit fast allen Tools zur Abhängigkeitsverwaltung können Sie ein privates Repository für Ihre Abhängigkeiten erstellen, das einer Versions- und Namenskonvention folgt. Wenn Sie einen Build ausführen, löst das Abhängigkeitsverwaltungstool alle Ihre Open Source- und proprietären Abhängigkeiten aus einer Liste genehmigter Quellen auf und fügt sie dann in Ihren lokalen Cache ein. Wenn Sie das nächste Mal mit denselben Versionsabhängigkeiten bauen, ist bereits alles vorhanden und es geht viel schneller.

Ihr privates Repository kann dann mit herkömmlichen Dateisystem-Sicherungstools gesichert werden.

Dies vermeidet die Verlangsamung, die ich erlebt habe, als eine Tonne Binärdateien aus dem Quellbaum gezogen wurden, und verhindert, dass Ihr Repository viele schwer zu diffizierende Dateien hat. Es gibt nur einen Speicherort für eine bestimmte Abhängigkeit, nach Name und Versionsnummer, sodass keine Zusammenführungskonflikte zu lösen sind. Durch das Zwischenspeichern des lokalen Dateisystems müssen Sie sich nicht mit den Kosten befassen, die durch die Überprüfung entstehen, ob sich Ihre lokale Kopie geändert hat Sie ziehen Updates.

JasonTrue
quelle
8

Die Quellcodeverwaltung gilt für Quellen. Quellen sind das, was Sie nicht aus anderen Dingen aufbauen können. Einige Dateien, die als Quellen gelten, sind Binärdateien.

In meinem VCS sind viele Binärdateien eingecheckt, aber jede ist die Freigabeeinheit für ein Produkt, das ich nicht geschrieben und nicht gewartet habe. Dies könnte so etwas wie GNU ccRTP sein, das als komprimierter Tarball veröffentlicht wird. Dieser Tarball ist meine Quelle und wird zusammen mit der Infrastruktur eingecheckt, die ich benötige, um ihn in einem einzigen automatisierten Schritt in ein fertiges Produkt (in meinem Fall eine Makefile- und eine RPM-Spezifikation) zu verwandeln. Wenn es eine neue Version von ccRTP gibt, behandle ich den neuen Tarball als geänderte Quelle: Er wird in eine ausgecheckte Kopie verschoben, erstellt, getestet und an das VCS zurückgesendet. Ich habe dasselbe mit kommerziellen Produkten gemacht, die nicht im Lieferumfang der Quelle enthalten sind (Compiler, Bibliotheken usw.), und es funktioniert genauso. Anstatt das Paket zu entpacken, müssen Sie nur das Paket entpacken. Die Software, die die nächtlichen Builds ausführt, funktioniert nicht.make und fertige Produkte bekommen.

Die meisten VCSs verfügen über Funktionen, mit denen für Menschen lesbare Quellen einfacher zu handhaben und effizienter zu speichern sind. Die Aussage, dass sie nicht für Binärdateien geeignet sind, trifft jedoch nicht zu, wenn die eingegebenen Binärdateien ungestört wiederhergestellt werden. Wie ein VCS intern mit Binärdateien umgeht, hängt ganz davon ab, ob die Autoren es für sinnvoll hielten, nur Unterschiede zu speichern. Persönlich denke ich, dass das Speichern vollständiger Kopien einer ccRTP-Distribution bei 600 KByte pro Sekunde mehr als wettgemacht wird, weil ich eine Version davon zusammen mit all meinen anderen Quellen kennzeichnen kann.

Blrfl
quelle
4

Dies erinnert mich an das "jars in repository" -Problem, das Java vor einiger Zeit hatte. Benutzer, die Java-Apps erstellen, haben ihre Abhängigkeiten (binäre JAR-Dateien) in Repositorys verschoben. Jeder war damit zufrieden, denn wir hätten ein "Ein-Klick" -Bausystem und der Speicherplatz ist billig. Also wen interessiert das? Dann kam Maven und Sie konnten all diese Binärdateien loswerden und mit dem lokalen Cache-Repository immer noch Bullet-Prof-Builds verwalten. Sie haben immer noch ein Build-System mit einem Klick, aber die Quellcodeverwaltung muss nicht um Binärdateien herum mischen, die dort keinen Sinn ergeben.

Sie können also Binärdateien aus der Quellcodeverwaltung abrufen, aber dazu müssen Sie das Build-System optimieren, um sie zum Zeitpunkt der Erstellung abzurufen. Ohne dedizierte Software (wie Maven) kann dies eine Menge Aufwand bedeuten, um sie einfach rauszuholen.

Jacek Prucia
quelle
1
Ich mache mir Sorgen, den Build-Prozess zu verkomplizieren, hauptsächlich, weil große Teile des Teams Mathematiker und keine großen Fans von Prozessen sind.
Daniel Goldberg
3

Ihre Quellcodeverwaltung hält die Quellen für das, was Sie tun. Wenn ein gegebener Binär-Blob aus den Quellen rekonstruiert werden kann, ist er keine Quelle und sollte nicht in das Quellcode-Repository aufgenommen werden. In der Quellcodeverwaltung sollten nur nicht wiederherstellbare Blobs angezeigt werden.

Normalerweise verfügen Sie über einen anderen Repository- Netzwerkordner mit Binärblobs, die Sie im Laufe der Zeit aus den Quellen erstellt haben. Diese können für Kunden bereitgestellt oder in Projekten verwendet werden (anstatt jedes Mal alles von Grund auf neu zu erstellen).

Geben Sie es ein, wenn es sich um eine Quelle handelt. Nicht wenn nicht.


quelle
Wer würde das ablehnen? Interessant warum: D
Ich war es nicht, aber ich vermute, wer auch immer mit der zweiten Hälfte der Antwort nicht einverstanden war.
Joel Coehoorn
@JoelCoehoorn, interessant, denn genau das ist ein Maven-Repository.
2

Das Ziel ist es, in der Lage zu sein, den neuesten Code abzurufen und zu erstellen, ohne dass etwas installiert / eingerichtet werden muss (also ein "Single Click" -Build).

An vielen Orten, an denen ich schon war, bedeutet dies, Binärdateien von Abhängigkeiten einzuchecken. In anderen Fällen bedeutet dies, dass die Build-Skripte die Abhängigkeiten automatisch herunterladen und abrufen.

Siehe diesen Blog-Beitrag von Derek Greer zu diesem Thema.

Oded
quelle
2

Ich arbeite an einem Projekt mit zwei verschiedenen Build-Phasen

  • Das "Hauptprogramm" benötigt nur ein paar Binärdateien im Vergleich zu den Tausenden von Quelltextdateien, sodass die Binärdateien in das Repository eingecheckt werden. Das funktioniert gut.

  • Für den Build des Installationsprogramms sind viele Komponenten von Drittanbietern erforderlich (einige davon werden nur auf die Installations-CD kopiert, z. B. der Adobe Reader). Diese werden nicht in das Repository gestellt. Stattdessen befinden sich diese Komponenten auf einem Netzwerklaufwerk (auch in älteren Versionen), und die Erstellungsskripts kopieren sie an die richtige Stelle. Um reproduzierbare Builds zu erhalten, muss natürlich jeder darauf achten, keinen Ordner zu ändern, in dem die Komponenten von Drittanbietern gespeichert sind.

Beide Strategien funktionieren einwandfrei und erfüllen die Anforderung, dass das Auschecken aus der Quellcodeverwaltung alles beinhaltet, was Sie zum Kompilieren des Codes benötigen.

Doc Brown
quelle
1

Sie müssen alles aufbewahren, was Sie benötigen, um bestimmte Versionen des Produkts zu einem späteren Zeitpunkt neu zu erstellen.

Sie müssen jedoch nicht alles in der Quellcodeverwaltung behalten.

Ein Unternehmen führte ein eingefrorenes Server-Rack (da das Betriebssystem nur auf dieser bestimmten Hardware und die Toolchain nur auf diesem Betriebssystem ausgeführt wurden und die Quelle von dieser Toolchain abhängig war). Das kann ich nicht in die Quellcodeverwaltung einchecken.

Wenn Sie die Anforderungen für einen Build aufteilen müssen, besteht das Abrechnungsproblem darin, dass zwei Versionskontrollsysteme synchronisiert bleiben. ZB die Hardware-Box in diesem Schrank oder die VM oder die Binärdateien in diesem konservierten Backup-Volume passen zu dieser SVN-Quellcode-Revision usw. Dies ist unordentlicher als die Verwendung eines einzelnen Quellcodeverwaltungssystems, aber lösbar.

hotpaw2
quelle
0

In meinen Augen ist es sehr chaotisch, binär in SCM einzuchecken. Ich hatte ein sehr komplexes Projekt durchgeführt, das viele Abhängigkeiten zu Bibliotheken von Drittanbietern aufweist. Die Prinzipien, die wir übernommen haben:

  1. Der gesamte Quellcode wird mit SCM verwaltet
  2. Alle Abhängigkeiten werden mit Ivy verwaltet, das sich hervorragend in Eclipse integrieren lässt.

Das funktioniert ganz gut. Wir haben eine Konfigurationsdatei über die Version jeder externen Bibliothek, mit der der Quellcode kompiliert werden kann. Diese Konfigurationsdatei wird in SCM eingecheckt, sodass sie sich mit der Entwicklung des Quellcodes weiterentwickelt. Durch Anwendung dieses Ansatzes können wir einen Build exakt reproduzieren, ohne die Version externer Bibliotheken durcheinander zu bringen.

James Gan
quelle
0

Persönlich bin ich philosophisch geneigt, die Quellcodeverwaltung Zeiger auf die großen Binärdateien einchecken zu lassen (kleine Binärressourcen sind in Ordnung) und nicht den Inhalt der Datei. Dieser Zeiger würde einen Hash des Inhalts der Binärdatei enthalten.

Die Binärdatei selbst würde nicht von der Quellcodeverwaltung verwaltet. Es würde in einer Art Bibliothek gespeichert, in der es mit dem Zeiger oder speziell mit dem Hash abgerufen werden kann.

Git LFS und Git Annex tun das, aber sie versuchen auch, die Binärdateien in gewissem Umfang zu verwalten. Ich möchte nicht, dass sie das tun. Ich möchte, dass Git nur Prüfsummen speichert und mir mitteilt, ob sich meine Binärdateien geändert haben oder nicht - aber ich möchte nicht, dass Git versucht, sie zu verwalten und zu speichern. Ich möchte das selbst machen.

Ich denke, dass Git kleine und mittlere Binärdateien verarbeiten kann, aber ich bin nicht sicher, ob es das richtige Werkzeug für die Verwaltung großer Binärdateien ist.

Rolf
quelle