Subversion-Revisionsnummer über mehrere Projekte hinweg

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

  •  08-06-2019
  •  | 
  •  

Frage

Bei der Verwendung von Subversion (svn) zur Quellcodeverwaltung bei mehreren Projekten ist mir aufgefallen, dass die Revisionsnummer in allen Verzeichnissen meiner Projekte ansteigt.Um mein SVN-Layout zu veranschaulichen (mit fiktiven Projektnamen): 

    /NinjaProg/branches
              /tags
              /trunk
    /StealthApp/branches
               /tags
               /trunk
    /SnailApp/branches
             /tags
             /trunk

Wenn ich einen Commit für den Stamm des Ninja-Programms durchführe, erhalte ich beispielsweise die Meldung, dass es auf Revision 7 aktualisiert wurde.Nehmen wir an, ich nehme am nächsten Tag eine kleine Änderung an der Stealth-Anwendung vor und sie kommt als Revision 8 zurück.

Die Frage ist diese: Ist es allgemein anerkannte Praxis, bei der Verwaltung mehrerer Projekte mit einem Subversion-Server die Revisionsnummer unabhängiger Projekte über alle Projekte hinweg zu erhöhen? Oder mache ich es falsch und sollte für jedes Projekt individuelle Repositorys erstellen?Oder ist es etwas ganz anderes?

BEARBEITEN: Ich habe mit dem Markieren einer Antwort gezögert, weil klar geworden war, dass es Gründe für beide Ansätze gibt, und obwohl diese Frage an erster Stelle stand, möchte ich auf einige andere Fragen hinweisen, die letztendlich dieselbe Frage stellen:

Soll ich alle Projekte in einem oder mehreren Repositorys speichern?

Ein SVN-Repository oder mehrere?

War es hilfreich?

Lösung

Ich bin überrascht, dass niemand erwähnt hat, dass dies in Version Control with Subversion besprochen wird, das kostenlos online verfügbar ist. Hier.

Ich habe mich vor einiger Zeit über das Thema informiert und es scheint wirklich eine Frage der persönlichen Entscheidung zu sein. Es gibt einen guten Blog-Beitrag zu diesem Thema Hier.BEARBEITEN: Da der Blog anscheinend nicht verfügbar ist, (Archivierte Version hier), hier ist etwas von dem, was Mark Phippard zu diesem Thema zu sagen hatte.

Dies sind einige der Vorteile des Single-Repository-Ansatzes.

  1. Vereinfachte Verwaltung.Ein Satz Hooks zum Bereitstellen.Ein Repository zum Sichern.usw.
  2. Verzweigungs-/Tag-Flexibilität.Da sich der gesamte Code in einem Repository befindet, ist es einfacher, einen Zweig oder ein Tag zu erstellen, an dem mehrere Projekte beteiligt sind.
  3. Code einfach verschieben.Vielleicht möchten Sie einen Codeabschnitt aus einem Projekt übernehmen und ihn in einem anderen verwenden oder ihn in eine Bibliothek für mehrere Projekte umwandeln.Es ist einfach, den Code innerhalb desselben Repositorys zu verschieben und dabei den Verlauf des Codes beizubehalten.

Hier sind einige der Nachteile des Einzel-Repository-Ansatzes und Vorteile des Mehrfach-Repository-Ansatzes.

  1. Größe.Es könnte einfacher sein, mit vielen kleineren Repositorys umzugehen als mit einem großen.Wenn Sie beispielsweise ein Projekt zurückziehen, können Sie das Repository einfach auf einem Medium archivieren, es von der Festplatte entfernen und so Speicherplatz freigeben.Möglicherweise müssen Sie aus irgendeinem Grund ein Repository sichern/laden, beispielsweise um die Vorteile einer neuen Subversion-Funktion zu nutzen.Dies ist einfacher und mit weniger Auswirkungen möglich, wenn es sich um ein kleineres Repository handelt.Selbst wenn Sie dies letztendlich für alle Ihre Repositorys tun möchten, wird es weniger Auswirkungen haben, sie einzeln auszuführen, vorausgesetzt, es besteht kein dringender Bedarf, sie alle auf einmal auszuführen.
  2. Globale Revisionsnummer.Auch wenn dies kein Problem darstellen sollte, empfinden einige Leute es als eines und möchten nicht, dass die Revisionsnummer im Repository voranschreitet und dass inaktive Projekte große Lücken in ihrem Revisionsverlauf aufweisen.
  3. Zugangskontrolle.Während der Authz-Mechanismus von Subversion es Ihnen ermöglicht, den Zugriff nach Bedarf auf Teile des Repositorys einzuschränken, ist es noch einfacher, dies auf Repository-Ebene zu tun.Wenn Sie ein Projekt haben, auf das nur wenige ausgewählte Personen zugreifen sollen, ist dies einfacher, wenn Sie ein einziges Repository für dieses Projekt verwenden.
  4. Administrative Flexibilität.Wenn Sie über mehrere Repositorys verfügen, ist es einfacher, je nach den Anforderungen des Repositorys/der Projekte unterschiedliche Hook-Skripte zu implementieren.Wenn Sie einheitliche Hook-Skripte wünschen, ist ein einzelnes Repository möglicherweise besser. Wenn jedoch jedes Projekt seinen eigenen Commit-E-Mail-Stil haben möchte, ist es einfacher, diese Projekte in separaten Repositorys zu haben

Wenn Sie wirklich darüber nachdenken, werden die Revisionszahlen in einem Repository mit mehreren Projekten zwar hoch werden, Ihnen aber nicht ausgehen.Beachten Sie, dass Sie den Verlauf eines Unterverzeichnisses anzeigen und schnell alle Revisionsnummern sehen können, die zu einem Projekt gehören.

Andere Tipps

Ich denke, es wird dringend empfohlen, für jedes Projekt separate Repositorys zu erstellen.Schon allein, um das Szenario zu vermeiden, von dem Sie sprechen.

Mit der Versionskontrolle, insbesondere Subversion, können Sie problemlos Teile eines Repositorys in eine andere Arbeitskopie auschecken und sie dann wieder in ihre jeweiligen Repositorys zurückschreiben.Das ermöglicht Ihnen eine klare Trennung und Unterscheidung bei gleichzeitig großer Flexibilität.Sobald Sie ein wenig mehr mit SVN vertraut sind (ich gehe davon aus, dass Sie neu sind), können Sie mit der Verwendung von Hooks beginnen, und ich sehe vielleicht, wo das bei Ihrem Setup schwierig werden könnte.Wenn Ihnen Berechtigungen wichtig sind, könnte sich ein einzelnes Repository als schwieriger als nötig erweisen.

Wenn Sie außerdem befürchten, dass die Einrichtung jedes Repositorys viel Zeit in Anspruch nehmen wird, sehen Sie sich die SVNParentPath-Variable für die Apache-Konfigurationsdatei an.(Auch hier gehe ich davon aus, dass Sie Apache verwenden.)

Das liegt an der Funktionsweise von Subversion.Jede Revision ist eigentlich eine Momentaufnahme des Repositorys, das durch diese Revisionsnummer identifiziert wird.Wenn sich alle Ihre Projekte ein Repository teilen, ist dies unvermeidlich.Normalerweise würde man meiner Erfahrung nach jedoch separate Repositorys für völlig unabhängige Projekte einrichten.Die kurze Antwort lautet also: Nein, Sie machen nichts falsch. Das ist eine häufige Frage im Zusammenhang mit Subversion, aber sie macht Sinn, wenn Sie darüber nachdenken, wie Repository-Informationen gespeichert werden.

Die Revisionsnummer sollte eigentlich nur eine Kennung für eine bestimmte Version sein.Ob es für ein Projekt sequentiell ist oder nicht, sollte keine Rolle spielen.Trotzdem kann ich verstehen, dass es nicht ideal ist.

Die meisten Projekte, auf die ich gestoßen bin, wurden in einem einzigen Repository eingerichtet und die Revisions-IDs verhalten sich auf diese Weise.Ich kenne keine SVN-Konfigurationsoption, um dieses Verhalten zu ändern, und meiner Meinung nach scheint die Verwaltung mehrerer Repositorys ein unnötiger Mehraufwand zu sein.

Wir haben nur ein Repository mit allem darin, ziemlich genau wie Ihr Beispiel.

Daran kann ich nichts Falsches erkennen – die einzige Voraussetzung für die Revisionsnummer ist, dass sie vorhanden ist

  • Einzigartig
  • Atomar
  • Größer als beim letzten Einchecken

Für mich spielt es keine Rolle, ob es sich mit jedem Commit um 1 oder 50 erhöht.

@grom:

Wenn ich dann ein neues Projekt starte, führe ich einfach Folgendes aus:

svnadmin create /var/www/svn/myproject

Ich kann mir vorstellen, dass das gut funktioniert, wenn Sie nur 1 oder 2 Entwickler haben, aber was passiert, wenn die Leute, die neue Projekte erstellen, keinen Shell-Zugriff auf den SVN-Server haben, um Verzeichnisse unter /var/www erstellen zu können?

Es wird empfohlen, pro Projekt ein separates Repository zu verwenden.In meinem Apache conf.d-Verzeichnis habe ich subversion.conf, das Folgendes enthält:

<Location /svn>
  DAV svn
  SVNParentPath /var/www/svn

  AuthType Basic
  AuthName "Subversion Repository"
  AuthUserFile /var/www/svn/password
  Require valid-user
</Location>

Wenn ich dann ein neues Projekt starte, führe ich einfach Folgendes aus:

svnadmin create /var/www/svn/myproject

Hm, wo ich arbeite, haben wir alle unsere Projekte im selben Repository.Ich sehe wirklich keinen Nutzen darin, sie zu trennen. Ist das nicht mit einer Menge zusätzlicher Arbeit verbunden – das Erstellen neuer Repositorys, das Gewähren des Zugriffs für Personen usw.?Ich denke, dass separate Repositorys sinnvoll sind, wenn die Projekte völlig voneinander unabhängig sind und Sie beispielsweise externe Kunden haben, die Zugriff auf das Repository benötigen.

An meinem Arbeitsplatz haben wir zwei Repositories.Eines mit öffentlichem Lesezugriff und eines für alles andere.Ich würde für alles nur eines verwenden, aber wir benötigen unterschiedliche Zugriffsrechte für öffentliche/private Projekte.

Allerdings sehe ich persönlich kein Problem darin, dass die Revisionsnummern bei jedem Update erhöht werden.Die Revisionsnummern könnten Primzahlen und gerade Zahlen überspringen und trotzdem tun, was sie tun sollen.Erleichtern Sie den Zugriff auf eine bestimmte Revision.

Wenn es Sie stört, dass sich die Revisionsnummern aufgrund anderer Projekte ändern, legen Sie die Projekte in separaten Repositorys ab.Nur so können die Revisionsnummern unabhängig gemacht werden.

Meiner Meinung nach besteht der Hauptgrund für die Verwendung verschiedener Repositorys darin, eine separate Zugriffskontrolle für Benutzer bereitzustellen und/oder unterschiedliche Hook-Skripte zu verwenden.

Vielleicht ist es am besten, nicht unbedingt ein Repo pro „Projekt“ zu erstellen, sondern eher ein Repo pro „Lösung“ (um die Begriffe von Visual Studio zu verwenden).Wenn Sie eine Reihe von „Projekten“ in verschiedenen Ordnern haben, die jedoch miteinander in Beziehung stehen, legen Sie sie im selben Repo ab.

Ich speichere ein Projekt pro Repository und mag ein vorheriges Kommentator dazu Subversion-Frage, markiere ich freigegebene Projekte als extern, sodass sie nur einmal in der Quellcodeverwaltung sind.

Ich fange gerade erst an, einen CI-Build-Server (CruiseControl.NET) hinzuzufügen, also muss ich sehen, wie das alles klappt, aber wenn meine Build-Skripte stimmen, sollte das kein Problem sein.

Abgesehen vom Aussehen ist es jedoch wirklich eine Frage der Präferenz (meiner Meinung nach).

Wenn Sie wirklich darüber nachdenken, werden die Revisionsnummern in einem Mehrfachprojekt -Repository hoch, aber Sie werden nicht ausgehen.Denken Sie daran, dass Sie eine Geschichte in einem Sub -Verzeichnis anzeigen und schnell alle Revisionsnummern sehen können, die sich auf ein Projekt beziehen.

Wenn Sie tatsächlich Microsoft-Code erstellen und die SVN-Revisionsnummern als Teil Ihrer Versionszeichenfolge verwenden, könnte Ihnen der Code ausgehen.Der Microsoft-Compiler gibt einen Fehler aus, wenn ein Teil der Versionszeichenfolge größer als 65535 ist....In unserem Fall haben wir ein riesiges Repository mit Revision 68876 und sind gerade an dieser Grenze angelangt.

Ein Repository pro Projekt.

Steven Murawskis Kommentar zu CC.NET ist interessant.Es würde mich interessieren, wie es funktioniert, wenn Sie mehrere Quellcodeverwaltungs-Repositorys angeben müssen.

@Daniel Fone:Die SVN-Dokumente empfehlen ein Projekt pro Repository, das ist also definitiv die Absicht der Ersteller.Da ein Server (Apache oder Svnserve) mehrere Repositorys verwalten kann, bin ich noch nie auf das Problem eines zu hohen Overheads gestoßen.Mit VisualSVN-Server, ist die Installation eines Apache-Servers und die Konfiguration mehrerer Repositorys ein Kinderspiel.

Ich bin nicht sicher, ob die SVN-Dokumente tatsächlich ein Projekt pro Repository empfehlen.Meistens sprechen sie über die Vor- und Nachteile jedes Weges.Ich verwende zufällig drei verschiedene Repositorys, eines für 7 oder 8 Projekte, die alle miteinander verbunden sind. Daher ist es sehr angenehm, kompatible Kopien aller Projekte versenden zu können, indem man einfach aus einer Revision erstellt (oder durch Ansehen überprüft, ob sie kompatibel sind). siehe jeweils die Revisionsnummern).Das zweite Repository enthält eine weitere Gruppe verwandter Projekte und Dokumente, während das dritte viel kleiner ist.Dadurch können wir uns die Tatsache zunutze machen, dass die zugehörigen Projekte mit einer einzigen Revisionsnummer verwaltet werden können, nicht verwandte Projekte jedoch keinen Einfluss auf ihr Repository haben.

Die Revisionsnummern haben keinen semantischen Nutzen.Das Einzige ist, dass sie in sequentieller Reihenfolge vorliegen.Wenn Sie Ihr Projekt sichern und in ein anderes Repository importieren, können Ihre Versionen neue Revisionsnummern erhalten.Also NIEMALS Verwenden Sie die Revisionsnummern, um Ihre Veröffentlichungen oder ähnliches zu kennzeichnen.Erstellen Sie Tags für Releases (Kopien der relevanten Revision).

Hatte das gleiche Problem in meiner vorherigen Firma. Früher liefen etwa 50 Projekte in einem Repository und es war ein Albtraum, an denselben Projekten zu arbeiten, weil andere bei der Durchführung von SVN-Updates fluchen würden ... lol ...

Eines habe ich gelernt, das immer am besten funktioniert: Ein Projekt, ein Repo ... Sie werden es nie bereuen.

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