Wie gehen Sie mit der Einrichtung der Quellcodeverwaltung eines nicht kompilierten -Projekts um, das von einem separaten Framework oder einer separaten Bibliothek abhängig ist? Zum Beispiel verwendet Projekt A Framework B. Sollte Projekt A auch den Code von Framework B in sein Repository aufnehmen? Gibt es eine Möglichkeit, dass es automatisch aus einem anderen Repository eingebunden wird oder müsste ich es manuell aktualisieren? Welche generellen Ansätze werden normalerweise für dieses Szenario gewählt? Angenommen, ich kontrolliere die Repositories sowohl für Projekt A als auch für Framework B und dass der Quellcode für beide nicht kompiliert wird.
Alle Ressourcen oder Vorschläge werden sehr geschätzt. Ich benutze derzeit Subversion (auf einer sehr grundlegenden Ebene), aber ich würde gerne zu Mercurial wechseln, damit ich Ofen mit Fogbugz ausprobieren kann.
Edit: Würden Sie in Mercurial übergeordnete Repositories für diese Funktion verwenden?
Wenn Sie Subversion verwenden und Code aus einem anderen Repository einschließen möchten, Subversion Externals könnte eine Option sein.
Wenn Sie jedoch mit kompilierbarem Code arbeiten, ist es möglicherweise besser, einen Build-Prozess einzurichten, der nur die erforderlichen Binärdateien abruft. Build-Tools wie Maven können dir dabei helfen.
Die meiste Zeit versuche ich alles Notwendige einzubauen, um das Projekt in Subversion zu bauen. Dies verwendet C # und Visual Studio, so dass die meisten meiner Abhängigkeiten DLLs sind. Konventionen können in anderen Umgebungen ein wenig variieren.
So plane ich normalerweise ein neues Projekt:
So kann es ohne großen Aufwand von einem neuen Entwickler ausgecheckt und erstellt werden. In der Vergangenheit verwendeten sie eine Netzwerkfreigabe für die dlls, aber das wurde nervig, da verschiedene Projekte verschiedene Versionen verwendeten und wenn man in Subversion oder Branch oder irgendetwas zurückgehen wollte, wurde es schwer, den Überblick zu behalten. Diese Struktur löste diese Probleme gut.
Ich mache etwas sehr ähnliches wie David Hogue, nur dass es so aussieht:
%Vor%Die meisten Inspirationen für dieses Setup kamen von Baumchirurgen (inzwischen ziemlich veraltet)
Wenn B ein Open-Source-Projekt ist und Sie es mit A kompilieren möchten, würde ich vorschlagen, dass Sie das Händler Drop Technik. Auf diese Weise können Sie Ihren eigenen Patch behalten.
Wenn B der proprietäre Code Ihres Unternehmens ist und Sie ihn nicht kompilieren möchten, wäre es viel einfacher, die kompilierten Binärdateien einfach in A 'repo zu kopieren.
Tags und Links dependencies svn mercurial version-control