Wie verwaltet man gemeinsam genutzte Bibliotheken?

Question

Jedes Mal, wenn ich ein Projekt erstelle, entwickle ich mehrere generische Routinen/Module/Bibliotheken, die ich in anderen Projekten verwenden werde.

Aufgrund der Geschwindigkeit der Entwicklung verbringe ich nicht viel Zeit damit, diese Module perfekt zu machen - gerade gut genug für dieses Projekt und gut genug dokumentiert und isolierbar, dass ich sie leicht einem anderen Projekt hinzufügen kann.

So weit, so gut.

Wenn ich sie nun in einem anderen Projekt verwende, verbessere ich sie zwangsläufig - entweder füge ich neue Merkmale/Funktionen hinzu, behebe Fehler, mache sie allgemeiner, usw.

An diesem Punkt habe ich mehrere Probleme:

• Ich muss die Änderungen im Modul für den Code, an dem ich gerade arbeite, beibehalten
• Ich muss dieselben Änderungen in einem zentralen "Modul"-Repository verwalten
• Ich muss sicherstellen, dass die aktualisierten Module verfügbar sind, aber nicht automatisch in älteren Projekten verwendet werden, oder manchmal sogar in bestehenden Projekten, an denen ich bereits arbeite.

Wie schaffen Sie das? Wie unterscheiden sich diese Probleme, wenn Sie Teams haben, die an verschiedenen Modulen in verschiedenen Projekten arbeiten?

-Adam

Answer 1

Wenn Sie Subversion für alle Ihre Projekte verwenden, können Sie einfach svn:externals : Dies ermöglicht es einem Repository, ein anderes Repository zu referenzieren, optional auf eine bestimmte Revision festgelegt. Zum Beispiel,

svn://svn/shared
svn://svn/project1
  |- dir1
  |- dir2
  \\- svn:externals "shared -r 3 svn://svn/shared"
svn://svn/project2
  |- dir3
  \\- svn:externals "shared -r 5 svn://svn/shared"

Übertragen Sie Ihre Änderungen in svn://svn/shared und ändern Sie die svn:externals Eigenschaft in den einzelnen Projekten, wenn Sie bereit sind.

Andernfalls könnten Sie bei der Verwendung anderer VCS einfach eine Reihe von Tags auf shared eine für jedes Projekt mit shared und verweist auf die von ihnen verwendete Version. Erweitern Sie jedes Tag auf spätere Versionen, wenn Sie bereit sind. Dies erfordert die manuelle Aktualisierung der Kopie jedes Projekts von shared Allerdings (eine Sache, die die svn:externals schön ist, dass dies automatisch geschieht).

Wenn Sie forken/verzweigen shared für jedes einzelne Projekt... nun, das kann funktionieren, aber es erfordert Arbeitskraft, um Änderungen zu pflegen und zusammenzuführen.

[Bearbeiten]

Weitere Referenzen:

Ver Externe Definitionen im svn-Buch für eine Anleitung und weitere Einzelheiten zu svn:externals und git-submodule anleitung für ein ähnliches Merkmal in der DVCS git .

Answer 2

Verwenden Sie natürlich die Versionskontrolle, wie PersistenceOfVision sagte, und führen Sie auch einen nächtlichen Build durch, um sicherzustellen, dass Sie alte Projekte nicht zerstören.

Answer 3

Wenn der Code so allgemein ist, dass Sie ihn in mehreren Projekten verwenden, ist es dann möglich, dass Sie das Rad neu erfinden? Wenn Sie stattdessen auf bestehende Bibliotheken zurückgreifen, verfügen Sie über einen bereits gut getesteten und optimierten Code, den Sie nicht mehr pflegen müssen.

Answer 4

Wählen Sie ein Software-Versionskontrollpaket Ihrer Wahl...

Zum Beispiel:
SVN + TortoiseSVN ist unsere aktuelle Lösung. (Kostenlos)
Einige bevorzugen Visual Source Safe. (Nicht frei)