Ist es empfehlenswert, binäre Abhängigkeiten in der Quellcodeverwaltung zu speichern?

Lesezeit: 6 Minuten

Benutzeravatar von Steve Dunn
Steve Dunn

Im Laufe der Jahre habe ich immer binäre Abhängigkeiten in der \lib Ordner und checkte ihn mit dem Rest des Projekts in die Quellcodeverwaltung ein. Ich finde, dass ich das jetzt weniger mache, da wir NuGet und die NuGet-Paketwiederherstellung haben.

Ich habe gehört, dass einige Unternehmen eine Regel erzwingen, dass keine Binärdateien in die Quellcodeverwaltung eingecheckt werden können. Als Gründe werden genannt:

  1. Die meisten VCS kommen mit Binärdateien nicht gut zurecht – Vergleichen und Zusammenführen wird nicht gut unterstützt
  2. Die Festplattennutzung steigt
  3. Commits und Updates sind langsamer
  4. Die zusätzliche Funktionalität, Kontrolle und Benutzerfreundlichkeit, die ein Repository-Manager standardmäßig bietet, gehen verloren
  5. Es fördert weitere schlechte Praktiken; Idealerweise sollten Projekte versuchen, ihre Builds vollständig zu automatisieren, das Einchecken in die Versionskontrolle ist normalerweise ein manueller Schritt

Gibt es objektive Argumente für oder gegen diese Praxis für die überwiegende Mehrheit der Projekte, die Quellcodeverwaltung verwenden?

Benutzeravatar von Thomas Weller
Thomas Weller

Ich würde Ihnen dringend empfehlen, die von Ihnen beschriebene Praxis NICHT zu verwenden (die Praxis, Binärdateien in der Quellcodeverwaltung zu verbieten). Eigentlich würde ich das ein organisatorisches Anti-Pattern nennen.

Die wichtigste Regel ist:

Sie sollten in der Lage sein, ein Projekt auf einem neuen Computer auszuchecken, und es muss sofort kompiliert werden.

Wenn dies über NuGet möglich ist, dann ist das in Ordnung. Wenn nicht, checken Sie die Binärdateien ein. Wenn es rechtliche/lizenzrechtliche Probleme gibt, sollten Sie mindestens eine Textdatei (mit dem Namen how_to_compile.txt oder ähnliches) in Ihrem Repo, das alle erforderlichen Informationen enthält.

Ein weiterer sehr starker Grund, dies so zu tun, ist die Vermeidung von Versionsproblemen – oder wissen Sie

  • welche genaue Version einer bestimmten Bibliothek vor einigen Jahren in Betrieb war und
  • ob es WIRKLICH die tatsächliche Version war, die im Projekt verwendet wurde und
  • wahrscheinlich am wichtigsten: wissen Sie, wie Sie genau diese Version bekommen?

Einige andere Argumente dagegen:

  • Das Einchecken von Binärdateien erleichtert die Build-Automatisierung erheblich (und behindert sie nicht). Auf diese Weise kann das Build-System alles, was es braucht, ohne weiteres von VCS bekommen. Wenn Sie es anders machen, sind immer manuelle Schritte erforderlich.
  • Leistungsüberlegungen sind völlig irrelevant, solange Sie in einem Intranet arbeiten, und nur von sehr geringer Bedeutung, wenn Sie ein webbasiertes Repository verwenden (ich nehme an, wir sprechen von nicht mehr als, sagen wir, 30-40 MB, was nicht wirklich der Fall ist eine große Sache für die heutigen Bandbreiten).
  • Dabei geht keinerlei Funktionalität verloren. Das stimmt einfach nicht.
  • Es stimmt auch nicht, dass normale Commits etc. langsamer sind. Dies ist nur der Fall, wenn es um die großen Binärdateien selbst geht, was normalerweise nur einmal vorkommt.
  • Und wenn Sie Ihre binären Abhängigkeiten eingecheckt haben, haben Sie zumindest manche Kontrolle. Wenn nicht, hast du gar keine. Und das hat sicherlich eine viel höhere Fehlerwahrscheinlichkeit …

  • Da fast alle modernen Programmierplattformen Paketsysteme verwenden, verlieren Ihre Argumente den Sinn. Sie haben Recht, dass “Sie in der Lage sein sollten, ein Projekt auf einem neuen Computer auszuchecken, und es muss sofort kompiliert werden.” und dies wird durch die Verwendung eines richtig abgestimmten Paketverwaltungssystems erreicht. Im SOURCE-Code-Repository sollten keine Binärdateien gespeichert werden.

    – Win4ster

    22. Februar 2021 um 18:04 Uhr

  • @Win4ster Das gilt nur, wenn Ihre Abhängigkeiten unter Ihrer Kontrolle sind. Wenn Sie externe Bibliotheken packen müssen, die keine richtigen Versionsinformationen in ihrem Namen haben und nicht über öffentliche Registrierungen verfügbar sind, ist es meiner Meinung nach immer noch der richtige Weg, sie in die Versionskontrolle zu versetzen.

    – Frank Schmidt

    4. Februar 2022 um 8:53 Uhr

  • @FrankSchmitt In den meisten Verpackungssystemen können Sie Ihr eigenes privates Repository für solche Artefakte erstellen und / oder sie bei Bedarf in Ihre eigenen internen Pakete einfügen.

    – Win4ster

    9. Februar 2022 um 15:11 Uhr


  • Quelle Steuersystem – ist KEIN Ort für Binärdateien!

    – Win4ster

    9. Februar 2022 um 15:13 Uhr

Meine eigene Faustregel besagt, dass generierte Assets nicht versioniert werden sollten (unabhängig davon, ob sie binär oder textuell sind). Es gibt verschiedene Dinge wie Bilder, Audio-/Videodateien usw., die aus gutem Grund eingecheckt werden können.

Zu den konkreten Punkten.

  1. Sie können diese Art von Dateien nicht zusammenführen, aber sie werden normalerweise nur ersetzt und nicht stückweise zusammengeführt. Sie können für einige Dateien mit benutzerdefinierten Unterschieden unterschieden werden, aber im Allgemeinen erfolgt dies mit einer Art Metadaten wie Versionsnummern.

  2. Wenn Sie eine große Textdatei hatten, ist die Festplattennutzung kein Argument gegen die Versionskontrolle. Ebenfalls. Die Idee ist, dass Änderungen an dieser Datei nachverfolgt werden müssen. Im schlimmsten Fall ist es möglich, diese Assets in ein separates Repository zu legen (das sich nicht oft ändert) und es dann mit etwas Git-Submodulen in das aktuelle einzubinden.

  3. Das stimmt einfach nicht. Vorgänge für diese bestimmte Datei sind möglicherweise langsamer, aber das ist in Ordnung. Dasselbe gilt für Textdateien.

  4. Ich denke, Dinge in der Versionskontrolle zu haben, erhöht den Komfort, den das Repo bietet. Manager.

  5. Dies berührt meinen Punkt, dass die fraglichen Dateien nicht generiert werden sollten. Wenn die Dateien nicht generiert werden, ist das Auschecken und Erstellen ein Schritt. Es gibt keine Phase „binäre Assets herunterladen“.

Es kommt auf den Workflow und das verwendete VCS an.

Unter Verwendung eines komponentenbasierten Workflows mit SVN checken Sie die Includes und Bibliotheken der Komponente ein. Damit bilden die Libs und Includes die Schnittstelle zu anderen Komponenten. Diese importieren nur die Libs und Includes unter Verwendung von svn:externals, während der Quellcode der Komponente überhaupt nicht importiert wird. Dies erzwingt saubere Schnittstellen und eine strikte Trennung zwischen den verschiedenen Komponenten: Eine Komponente ist eine Blackbox, die nur so verwendet werden kann, wie sie in der Schnittstelle angegeben ist. Die interne Struktur ist für andere unsichtbar. Die Verwendung von Binärdateien reduziert die Kompilierzeit und kann die Anzahl der Tools reduzieren, die auf einem Computer zum Kompilieren erforderlich sind, da spezialisierte Tools, die zum Erstellen einer Komponente erforderlich sind, nicht vorhanden sein müssen, wenn sie nur verwendet werden.

Bei Verwendung eines verteilten VCS funktionieren die Dinge jedoch nicht auf diese Weise. DVCS hängt davon ab, das gesamte Repository zu klonen. Beim Einchecken von Binärdateien wächst die Größe des Repositorys schnell über einen Punkt hinaus, an dem dies einfach zu lange dauert. Während SVN-Repositories mit 100 GB kein Problem sind, da Checkouts nur mit einer Revision umgehen, die um mehrere Größenordnungen kleiner ist, würde ein Git/Mercurial/Bazaar-Repository dieser Größe es ziemlich unbrauchbar machen, da das Klonen ewig dauern würde.

Ob das Einchecken von Binärdateien eine gute Idee ist oder nicht, hängt also von Ihrem Arbeitsablauf und auch von den verwendeten Tools ab.

Fast alle modernen Programmierplattformen haben ihre Paketmanager. Das bedeutet, dass gemeinsam genutzte Binärdateien besser in Pakete gebündelt und mit dem Paketverwaltungssystem veröffentlicht werden sollten. Sogar Binärdateien und Ressourcen von Drittanbietern, die keine entsprechenden offiziellen Pakete haben, können Sie in Ihre eigenen Pakete einpacken, in Ihrem privaten Paket-Repository speichern und in den meisten Fällen in Ihrem eigenen CI/CD-System zum Erstellen Ihrer Produkte verwenden. So für Quelle Code verwenden Quelle Code-Repository und für Binärdateien und Abhängigkeiten von Drittanbietern verwenden Sie Paketverwaltungssysteme. Trennung von Bedenken.

1445590cookie-checkIst es empfehlenswert, binäre Abhängigkeiten in der Quellcodeverwaltung zu speichern?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy