Umgang mit Beziehungen zwischen mehreren Subversion Projekte

StackOverflow https://stackoverflow.com/questions/1405091

Frage

In meiner Firma verwenden wir eine SVN-Repository unseren C ++ Code zu halten. Die Code-Basis ist aus einem gemeinsamen Teil zusammengesetzt (Infrastruktur und Anwendungen) und Client-Projekte (als Plugins entwickelt).

Das Repository Layout sieht folgendermaßen aus:

  • Infrastruktur
  • App1
  • App2
  • Anw3
  • Projekt-für-client-1
    • App1-Plugin
    • App2-Plugin
    • Konfiguration
  • Projekt-für-client-2
    • App1-Plugin
    • App2-Plugin
    • Konfiguration

Eine typische Freisetzung für ein Client-Projekt umfasst die Projektdaten und jedes Projekt, das von ihr (z Infrastructure) verwendet wird.

Die tatsächliche Layout jedes Verzeichnisses ist -

  • Infrastruktur
    • Zweige
    • Tags
    • Stamm
  • Projekt-für-client-2
    • Zweige
    • Tags
    • Stamm

Und das gleiche gilt für den Rest der Projekte.

Wir haben mehrere Probleme mit dem Layout oben:

  1. Es ist schwer, eine neue Entwicklungsumgebung für ein Client-Projekt zu starten, da man alle beteiligten Projekte zur Kasse hat (zum Beispiel: Infrastruktur, App1, App2, Projekt-for-Client-1).
  2. Es ist schwer, wie oben Release in einem Client-Projekten aus dem gleichen Grunde zu markieren.
  3. Falls ein Client-Projekt einig gemeinsamen Code (z Infrastructure) geändert werden muß, wir manchmal einen Zweig verwenden. Es ist schwer, den Überblick zu behalten, die Niederlassungen in Projekten verwendet werden.

Gibt es eine Möglichkeit in SVN eine der oben genannten zu lösen? Ich dachte, die Verwendung von svn: externals in den Client-Projekten, aber nach der Lektüre diesen Beitrag ich es verstehe nicht richtige Wahl sein könnte.

War es hilfreich?

Lösung

Sie könnten damit umgehen mit svn: externals. Dies ist die URL zu einer Stelle in einer SVN-Repo Auf diese Weise können Sie in Teilen eines anderen Repository (oder die gleichen) ziehen. Eine Möglichkeit, dies zu verwenden, ist unter Projekt-for-client2, fügen Sie ein svn: externals verlinken auf dem Zweig der Infrastruktur, die Sie benötigen, die Niederlassung der app1 Sie benötigen, etc. Also, wenn Sie Projekt-for-client2 Check-out, Sie bekommen alle richtigen Stücke.

Die svn:. Externe Links versioniert werden zusammen mit alles anderen, so als Projekt-for-client1 getaggt bekommen, verzweigte und aktualisierte die richtigen Außenstellen werden immer in Mitleidenschaft gezogen bekommen

Andere Tipps

Ein Vorschlag ist, Verzeichnislayout ändern von

  • Infrastruktur
    • Zweige
    • Tags
    • Stamm
  • Projekt-für-client-1
    • Zweige
    • Tags
    • Stamm
  • Projekt-für-client-2
    • Zweige
    • Tags
    • Stamm

  • Niederlassungen
    • Feature-1
      • Infrastruktur
      • Projekt-für-client-1
      • Projekt-für-client-2
  • Tags
  • Stamm
    • Infrastruktur
    • Projekt-für-client-1
    • Projekt-für-client-2

Es gibt einige Probleme auch mit diesem Layout. Zweige werden massiv, aber zumindest ist es einfacher, bestimmte Stellen im Code zu markieren.

mit dem Code umgehen, würde man einfach den Stamm Kasse und damit arbeiten. Dann brauchen Sie nicht die Skripte, die alle verschiedene Projekte angeboten werden. Sie beziehen sich nur auf Infrastruktur mit „../Infrastructure“. Ein weiteres Problem bei diesem Layout ist, dass Sie mehrere Kopien zur Kasse benötigen, wenn Sie an Projekten arbeiten völlig unabhängig voneinander wollen. Andernfalls wird eine Änderung in der Infrastruktur für ein Projekt könnte ein anderes Projekt führt nicht zu kompilieren, bis das auch aktualisiert wird.

Dies könnte machen gibt ein wenig umständlicher zu, und den Code für verschiedene Projekte zu trennen.

Ja, es saugt. Wir tun das Gleiche, aber ich kann ein besseres Layout nicht wirklich denken.

Also, was wir haben, ist eine Sammlung von Skripten, die alles Subversion im Zusammenhang automatisieren. Jedes Projekt des Kunden enthält eine Datei namens project.list, die alle der Subversion Projekte / Pfade enthalten erforderlich, um diese Kunden zu bauen. Zum Beispiel: 

Infrastructure/trunk
LibraryA/trunk
LibraryB/branches/foo
CustomerC/trunk

Jedes Skript dann etwa wie folgt aussieht: 

for PROJ in $(cat project.list); do
    # execute commands here
done

Wenn die Befehle möglicherweise eine Kasse, zu aktualisieren oder ein Tag sein. Es ist ein bisschen komplizierter als das, aber es bedeutet, dass alles, was im Einklang ist, Check-out, Aktualisierung und Tagging wird zu einem einzigen Befehl.

Und natürlich versuchen wir so wenig wie möglich zu verzweigen, die der wichtigste Vorschlag ist, kann ich vielleicht machen. Wenn wir etwas verzweigen müssen, werden wir zu jeder Arbeit des Stammes oder die zuvor markierten Version von so viele der Abhängigkeiten wie möglich versuchen, aus.

Als erstes bin ich nicht einverstanden, dass Äußerlichkeiten sind böse. Obwohl sie sind nicht perfekt.

Im Moment Sie tun mehrere Kassen eine Arbeitskopie aufzubauen. Wenn Sie Externen verwendet würde es tun genau das, sondern automatisch und konsequent jedes Mal.

Wenn Sie Ihre externen Quellen-Tags (und oder spezifische Versionen) innerhalb der Zielprojekte verweisen, müssen Sie nur das aktuelle Projekt pro Veröffentlichung markieren (wie dieser Tag genau angeben würde, welche externen Sie deuten). Sie würden auch eine Aufzeichnung innerhalb des Projekts genau, wenn Sie Ihre Externen Referenzen geändert, um eine neue Version einer bestimmten Bibliothek zu verwenden.

Externals sind kein Allheilmittel - und als Beitrag zeigt kann es Probleme geben. Ich bin sicher, es ist etwas besser als Äußerlichkeiten, aber ich habe es noch nicht gefunden (auch vom Konzept her). Sicherlich ist die Struktur, die Sie verwenden können eine Vielzahl von Informationen und die Kontrolle in Ihren Entwicklungsprozess ergeben, Äußerlichkeiten verwendet, kann dem hinzufügen. die Probleme, die er hatte waren jedoch nicht grundlegende Fragen der Korruption - a. sauber get alles lösen würde, und sind ziemlich selten (? Sie sind wirklich nicht in der Lage eine Niederlassung einer Bibliothek in Ihrem Repo erstellen)

Was zu beachten ist - rekursive Äußerlichkeiten verwenden. Ich bin nicht auf entweder die ja oder nein dieser verkauft und sind in der Regel mit einem pragmatischen Ansatz gehen.

Betrachten Kolben mit wie der Artikel schon sagt, habe ich es nicht in Aktion gesehen kann also nicht wirklich kommentiert, kann es die gleiche Arbeit wie Äußerlichkeiten in einer besseren Art und Weise tun.

Aus meiner Erfahrung halte ich es für sinnvoller ist ein Repository für jedes einzelne Projekt zu haben. Ansonsten haben Sie die Probleme, die Sie sagen, und darüber hinaus, Revisionsnummern ändern, wenn andere Projekte ändern, welche verwirrend sein könnte.

Nur wenn es eine Beziehung zwischen dem einzelnen Projekten, wie zum Beispiel Software, Hardware Pläne, Dokumentation, etc. Wir ein einziges Repository verwenden, damit die Revisionsnummer die gesamte Packung in einen bekannten Zustand erhalten dient.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top