Ist es akzeptabel/gut, Binärdateien in SVN zu speichern?

Question

Wir würden gerne Laufzeitprojekt-Binärdateien austauschen. So könnte jedes Teammitglied die aktuelle Arbeitsversion übernehmen. Ist es akzeptabel/gut, Laufzeit-Binärdateien im SVN zu speichern?

Answer 1

Die beiden häufigsten Gründe, warum Sie Binärdateien in einem Versionskontrollsystem speichern möchten, sind (geschrieben im Jahr 2009):

• externe Bibliotheken von Drittanbietern speichern .
  Normalerweise speichert man sie in einem Maven-Repository, aber wenn man sie in SVN speichert, hat man die Möglichkeit eine und nur eine Bezugnahme für alles, was Sie brauchen: die Quellen und die Bibliotheken, die Sie zum Kompilieren der Quellen benötigen. Alles kommt aus einem Repository.

(Wie bemerkt von ivorujavaboy im Jahr 2017: "Der einzige gute Grund, dies derzeit zu tun, ist, wenn Sie STATISCHE Bibliotheken haben, die sich nie ändern werden, was ein wirklich seltener Fall ist")

• Lagerlieferungen für einen schnelleren Einsatz .
  Normalerweise werden Lieferungen (die ausführbare Datei, die Sie für die Bereitstellung in der Produktion erstellen) auf Anforderung erstellt.
  Aber wenn man viele Vorproduktionsumgebungen und viele Lieferungen hat, können die Kosten für den Bau von Montage-, Integrations-, Homologations- und Vorproduktionsplattformen hoch sein.
  Eine Lösung besteht darin, sie einmal zu erstellen, sie in einem Auslieferungsabschnitt Ihres SVN zu speichern und sie direkt in Ihrer anderen Umgebung zu verwenden.
  Nota:
  Dies gilt auch für Entwicklungselemente: Wenn Sie eine Jaxb Prozesses, der 900 POJO-Dateien (durch XML-Bindung) erzeugt, und Sie müssen diesen Entwicklungssatz in mehreren Umgebungen herunterladen, möchten Sie vielleicht lieber 1 komprimierte Dateikopietransaktion als 900.

Also ja, es ist "akzeptabel/gut, Laufzeit-Binärdateien im SVN zu speichern"... aus den richtigen Gründen.

---

Dies vorausgeschickt:

• Wim Coenen zu Recht nennt die Nachteile (schlechte Praxis, langsam, Unstimmigkeit zwischen Quellen und gespeicherter Lieferung)
• Wladimir setzt sich ein für die Verwendung einer Lieferungsreferenz (Nexus oder, wie Vladimir erwähnt, Apachen-Efeu )
• RogerV illustriert die Vorteile, die sich aus der Verwendung der Referenznummer für die Lieferung ergeben (In seinem Fall Nexus)

Answer 2

Nein, speichern Sie keine Binärdateien neben ihrem Quellcode (außer Sie haben gute Gründe, die die Nachteile aufwiegen).

Benachteiligungen:

• ermutigt er schlechte Build-Praktiken in großen Projekten. Die beste Praxis ist es, den Build vollständig zu automatisieren. Die Übergabe von Binärdateien ermöglicht es Ihnen, das zu ignorieren: "Einfach den Build für die Teile, die sich geändert haben, manuell durchführen" :-(
• langsamere Aktualisierungen und Übertragungen
• Commits, die zwar den Quellcode, nicht aber die entsprechenden Binärdateien ändern, führen zu Verwirrung unter den Entwicklern. Wie erkennen Sie, dass es eine Diskrepanz gibt?
• svn update aktualisiert den Zeitstempel Ihrer Binärdateien und verwirrt Ihre Build-Tools, die fälschlicherweise denken, dass die Binärdateien neuer sind als Ihre Quellcodeänderungen.
• verursacht unnötige Konflikte bei den Binärdateien für svn update y svn merge
• es wird mehr Speicherplatz im Repository benötigt. (Dies kann je nach Projekt vernachlässigbar sein.)

Vermeiden Sie es im Allgemeinen, irgendetwas zu übertragen, das automatisch auf deterministische Weise aus anderen versionierten Ressourcen generiert wurde. Keine Redundanz -> keine Möglichkeit für Inkonsistenzen.

Verwenden Sie stattdessen einen Continuous-Integration-Server, um bei jeder Übertragung automatisch ein neues Build zu erstellen (und die Tests auszuführen). Lassen Sie diesen Build-Server die Binärdateien irgendwo veröffentlichen (außerhalb von SVN), falls erforderlich.

Das heißt aber nicht, dass Sie dies als absolute Regel ansehen oder vermeiden sollten 何れも Binärdateien. Binden Sie auf jeden Fall Ihre Build-Tools und Closed-Source-Binärdateien von Drittanbietern in Ihre Projekte ein. Und machen Sie Ausnahmen, wenn es sinnvoll ist. Idealerweise sollte ein neuer Entwickler in der Lage sein, einen Check-Out durchzuführen und sofort das Build-Skript zu starten, ohne ein oder zwei Tage mit der Einrichtung seiner Umgebung zu verbringen.

Answer 3

Ich würde sagen: Wenn es Ihrem Team das Leben leichter macht, dann tun Sie es. Wenn es den Zeitaufwand für die Einrichtung einer funktionierenden Entwicklungsumgebung verringert, sollten Sie es tun.

Answer 4

Wie viele bereits gesagt haben, ist das akzeptabel.

Ja, es ist praktisch, alles an einem Ort zu haben, von dem aus man (zum Beispiel) ein älteres Tag bereits in binärer Form mit den richtigen Abhängigkeiten auschecken kann.

Aber es ist NICHT gut, vor allem für Sicherungszwecke. Wir haben alle unsere Binärdateien (und einen Teil der Abhängigkeiten) in SVN gespeichert, und als das Projekt wuchs, tat dies auch der Binärbereich.

Leider, svnadmin dump einfach alles auslagert, können Sie keinen Pfad des auszuschließenden Repositorys angeben. Dadurch wurden Backups (und Upgrades des svn-Servers) sehr mühsam!

Wenn man noch hinzufügt, dass diese Binärdateien in unserem Fall nach nicht allzu langer Zeit nicht mehr nützlich waren, bin ich sicher, dass ich das in einem ähnlichen Fall nicht noch einmal tun würde (aber bei einem kleineren Projekt würde ich es tun).

Ich würde also empfehlen, zweimal darüber nachzudenken, bevor man das tut, und zu versuchen, vorauszusagen, wie groß man wachsen kann und was sonst noch passieren könnte.

Answer 5

Nicht zu diesem Zweck, nein. Sie sollten einen externen Dateispeicher verwenden, z. B. einen FTP- oder Webserver. Auf diese Weise ist es einfach, eine bestimmte Version Ihrer Laufzeit-Binärdatei herunterzuladen, ohne zuerst auf diese Revision in SVN aktualisieren zu müssen.