Vor-und Nachteile für die Speicherung von Code und Daten in separaten Repositories

Question

Wir haben ein Projekt, das Daten und Code in einem einzigen Mercurial-Repository gebündelt hat. Die Daten sind genauso wichtig wie der Code (er enthält Parameter für die Geschäftslogik, einige Eingaben usw.) Das Format der Datendateien ändert sich jedoch selten, und es ist ganz natürlich, die Datendateien unabhängig vom Code zu ändern. Ein Vorteil des vereinheitlichten Repositories ist, dass wir nicht mehrere Revisionen verfolgen müssen: Wenn wir jemals die Ausgabe eines vorherigen Laufs neu erstellen müssen, müssen wir nur das System auf die einzige Revisionsnummer aktualisieren, die darin gespeichert ist das Ausgabeprotokoll

Ein Nachteil ist, dass wenn wir die Daten ändern, während mehrere Köpfe aktiv sind, können wir die Datenänderungen verlieren, wenn wir diese Änderungen nicht manuell auf jeden Kopf kopieren.

Gibt es noch weitere Vor-/Nachteile für die Aufteilung des Codes und der Daten in separate Repositories?

Answer 1

Multiple repos:

• Profis:

  • component-based approach (Sie identifizieren Gruppen von Dateien, die unabhängig voneinander entwickeln können)
  • Konfigurationsspezifikation: Sie Liste die Referenzen (hier "Revisionen") auf, die du für dich brauchst r System zu arbeiten. Wenn Sie einen Teil ändern möchten, ohne den anderen zu ändern, aktualisieren Sie diese Liste.
  • Teil Klone: ​​Wenn Sie nicht alle Komponenten benötigen, können Sie nur diejenigen klonen Sie wollen (nicht in Ihrem Fall keine Anwendung)

• cons Management

  • Konfiguration : Sie müssen diese Konfiguration verfolgen (normalerweise durch ein Eltern-Repo, Registrierung subrepos)
  • in Ihrem Fall, Daten sind ziemlich abhängig von bestimmten Versionen der Projekte (Sie können neue Daten haben, die für alte Vers nicht sinnvoll ist Ionen des Projekts)

---

Ein Repo

• Profis
  • system-based approach: Sie Ihre Module als ein System (Projekt und Daten sehen).
  • Repo-Management: alle in einer
  • enge Verbindung zwischen den Modulen
• Nachteile
  • Datenübertragung (wenn, wie Sie erwähnen, mehrere HEAD sind (der Sinn für Daten macht) aktiv)
  • Zwischenrevisionen (nicht um eine neue Funktion zu reflektieren, sondern nur weil sich einige Daten ändern)
  • größerer Klon (nicht relevant hier, es sei denn, Ihre Daten große Binärdateien)

Für nicht-Binärdaten mit seltenen Änderungen, würde ich sie in der gleichen Repo noch halten.

Answer 2

Ja, Sie sollten Code und Daten trennen. Halten Sie den Code in der Versionskontrolle und Ihre Daten in einer Datenbank.

Ich liebe Versionskontrolle, da ich seit mehr als zehn Jahren Programmierer bin und diesen Job mag.

Aber in den letzten Monaten habe ich festgestellt: Daten dürfen nicht in Versionskontrolle sein. Manchmal ist es schwierig für jemanden, der mit Git (oder einem anderen Versionskontrollsystem) vertraut ist, "loszulassen".

Sie benötigen ein gutes ORM, das Datenbankschema-Migrationen unterstützt. Die Migrationen (Schemamigrationen und Datamigrationen) werden in der Versionskontrolle beibehalten, die Daten jedoch nicht.

Ich weiß, Ihre Frage war über die Verwendung von ein oder zwei Repositories, aber vielleicht hilft meine Antwort Ihnen, einen anderen Blickpunkt zu bekommen.