Ein SVN-Repository oder viele?

Wenn Sie mehrere Projekte haben, die nichts miteinander zu tun haben, ist es eine gute Idee, sie im selben Repository abzulegen?

myRepo/projectA/trunk
myRepo/projectA/tags
myRepo/projectA/branches
myRepo/projectB/trunk
myRepo/projectB/tags
myRepo/projectB/branches

oder würden Sie für jedes neue Repositorys erstellen?

myRepoA/trunk
myRepoA/tags
myRepoA/branches
myRepoB/trunk
myRepoB/tags
myRepoB/branches

Was sind die Vor- und Nachteile von jedem? Alles, woran ich derzeit denken kann, ist, dass Sie gemischte Revisionsnummern erhalten (na und?), Die Sie nur verwenden können, svn:externalswenn das Repository tatsächlich extern ist. (Meiner Ansicht nach?)

Der Grund, den ich frage, ist, dass ich erwäge, meine mehreren Repos zu einem zusammenzufassen, da mein SVN-Host damit begonnen hat, pro Repo Gebühren zu erheben.

Das Einzel- oder Mehrfachproblem hängt von den persönlichen oder organisatorischen Vorlieben ab.

Die Verwaltung von Multiple vs. Single hängt hauptsächlich von der Zugriffskontrolle und Wartung ab.

Die Zugriffssteuerung für ein einzelnes Repository kann in einer einzelnen Datei enthalten sein. Für mehrere Repositorys sind möglicherweise mehrere Dateien erforderlich. Die Wartung weist ähnliche Probleme auf - eine große Sicherung oder viele kleine Sicherungen.

Ich verwalte meine eigenen. Es gibt ein Repository, mehrere Projekte mit jeweils eigenen Tags, Trunk und Zweigen. Wenn einer zu groß wird oder ich den Code eines Kunden für seinen Komfort physisch isolieren muss, kann ich schnell und einfach ein neues Repository erstellen.

Ich habe mich kürzlich mit einer relativ großen Firma über die Migration mehrerer Quellcodeverwaltungssysteme zu Subversion beraten. Sie haben ~ 50 Projekte, von sehr kleinen bis hin zu Unternehmensanwendungen und ihrer Unternehmenswebsite. Ihr Plan? Beginnen Sie mit einem einzelnen Repository und migrieren Sie bei Bedarf zu mehreren. Die Migration ist fast abgeschlossen und sie befinden sich immer noch in einem einzigen Repository. Es wurden keine Beschwerden oder Probleme gemeldet, da es sich um ein einziges Repository handelt.

Dies ist kein binäres Schwarz-Weiß-Problem.

Tun Sie, was für Sie funktioniert - wäre ich in Ihrer Position, würde ich Projekte so schnell wie möglich in einem einzigen Repository zusammenfassen, da die Kosten in meinem (sehr, sehr kleinen) Unternehmen eine wichtige Rolle spielen würden.

JFTR:

Revisionsnummern in Subversion haben außerhalb des Repositorys wirklich keine Bedeutung. Wenn Sie für eine Revision aussagekräftige Namen benötigen, erstellen Sie eine TAG

Commit-Nachrichten lassen sich leicht nach Pfaden im Repository filtern. Daher ist es eine triviale Aufgabe, nur die Nachrichten zu lesen, die sich auf ein bestimmtes Projekt beziehen.

Bearbeiten: Weitere Informationen zur Verwendung einer einzelnen Autorisierungs- / Authentifizierungskonfiguration für SVN finden Sie in der Antwort von Blade .

Für Ihren speziellen Fall ist ein (1) Repository perfekt. Sie sparen viel Geld. Ich ermutige die Leute immer, ein einziges Repository zu verwenden. Weil es einem einzelnen Dateisystem ähnlich ist: Es ist einfacher

• Sie haben einen einzigen Ort, an dem Sie nach Code suchen
• Sie haben eine einzige Berechtigung
• Sie haben eine einzige Commit-Nummer (haben Sie jemals versucht, ein Projekt zu erstellen, das auf 3 Repos verteilt ist?)
• Sie können allgemeine Bibliotheken besser wiederverwenden und Ihren Fortschritt in diesen Bibliotheken verfolgen (svn: Externe sind PITA und lösen nicht alle Probleme).
• Projekte, die als völlig unterschiedliche Elemente geplant sind, können zusammenwachsen und Funktionen und Schnittstellen gemeinsam nutzen. Dies wird in mehreren Repos sehr schwierig zu erreichen sein.

Es gibt einen einzigen Punkt für mehrere Repositorys: Die Verwaltung großer Repos ist unangenehm. Das Dumping / Laden großer Repos nimmt viel Zeit in Anspruch. Aber da Sie keine Verwaltung durchführen, denke ich, dass es nicht Ihr Anliegen sein wird;)

SVN lässt sich sehr gut mit größeren Repositorys skalieren. Selbst bei großen Repositorys (> 100 GB) gibt es keine Verlangsamung.

So haben Sie weniger Probleme mit einem einzigen Repository. Aber Sie sollten wirklich über das Repo-Layout nachdenken!

Ich würde mehrere Repositorys verwenden. Zusätzlich zum Benutzerzugriffsproblem erleichtert es auch das Sichern und Wiederherstellen. Und wenn Sie sich in einer Position befinden, in der jemand Sie für Ihren Code (und dessen Verlauf) bezahlen möchte, ist es einfacher, ihm nur einen Repository-Speicherauszug zu geben.

Ich würde vorschlagen, dass die Konsolidierung von Repositorys nur aufgrund der Gebührenrichtlinien Ihres Hosting-Anbieters kein sehr guter Grund ist.

Wir verwenden ein einziges Repository. Mein einziges Anliegen war die Skalierung, aber nachdem ich das ASF-Repository (700.000 Revisionen und Zählung) gesehen hatte, war ich ziemlich überzeugt, dass die Leistung kein Problem darstellen würde.

Unsere Projekte sind alle verwandte, unterschiedliche ineinandergreifende Module, die eine Reihe von Abhängigkeiten für eine bestimmte App bilden. Aus diesem Grund ist ein einziges Repository ideal. Möglicherweise möchten Sie für jedes Projekt separate Trunk / Zweige / Tags, können jedoch innerhalb einer einzigen Revision atomar eine Änderung in Ihrer gesamten Codebasis festschreiben. Dies ist fantastisch für das Refactoring.

Beachten Sie, dass viele SVN-Repos bei Ihrer Entscheidung dieselbe Konfigurationsdatei verwenden können.

Beispiel (aus dem obigen Link):

In der Schale:

$ svn-admin create /var/svn/repos1
$ svn-admin create /var/svn/repos2
$ svn-admin create /var/svn/repos3

Datei: /var/svn/repos1/conf/svnserve.conf

[general]
anon-access = none # or read or write
auth-access = write
password-db = /var/svn/conf/passwd
authz-db = /var/svn/conf/authz
realm = Repos1 SVN Repository

Datei: / var / svn / conf / authz

[groups]
group_repos1_read = user1, user2
group_repos1_write = user3, user4
group_repos2_read = user1, user4

### Global Right for all repositories ###
[/]
### Could be a superadmin or something else ###
user5 = rw

### Global Rights for one repository (e.g. repos1) ###
[repos1:/]
@group_repos1_read = r
@group_repos1_write = rw

### Repository folder specific rights (e.g. the trunk folder) ###
[repos1:/trunk]
user1 = rw

### And soon for the other repositories ###
[repos2:/]
@group_repos2_read = r
user3 = rw

Ich würde separate Repositorys erstellen ... Warum? Die Revisionsnummern und Commit-Meldungen machen einfach keinen Sinn, wenn Sie viele unabhängige Projekte in nur einem Repository haben. Kurzfristig wird es mit Sicherheit ein großes Durcheinander sein.

Wir sind ein kleines Softwareunternehmen und verwenden für unsere gesamte Entwicklung ein einziges Repo. Der Baum sieht so aus:

/client/<clientname>/<project>/<trunk, branches, tags>

Die Idee war, dass wir Kunden und interne Arbeit im selben Repo haben würden, aber am Ende hatten wir unser Unternehmen als "Kunden" für sich.

Dies hat bei uns sehr gut funktioniert und wir verwenden Trac als Schnittstelle. Die Revisionsnummern beziehen sich auf das gesamte Repo und sind nicht projektspezifisch, aber das bringt uns nicht in Phase.

Persönlich würde ich für jedes neue Repositorys erstellen. Dies vereinfacht den Auscheckvorgang erheblich und erleichtert die Verwaltung insgesamt, zumindest im Hinblick auf den Benutzerzugriff und die Sicherungen. Außerdem wird das Problem der globalen Versionsnummer vermieden, sodass die Versionsnummer für alle Projekte von Bedeutung ist.

Wirklich aber, du solltest nur git benutzen;)

Eine weitere zu berücksichtigende Sache ist die Tatsache, dass die Verwendung mehrerer Repositorys dazu führt, dass Sie die Möglichkeit einer einheitlichen Protokollierung verlieren (Befehl svn log). Dies allein ist ein guter Grund für die Auswahl eines einzelnen Repositorys.

Ich benutze TortuiseSvn und habe festgestellt, dass die Option "Protokoll anzeigen" ein obligatorisches Tool ist. Obwohl Ihre Projekte nichts miteinander zu tun haben, werden Sie sicher feststellen, dass eine zentralisierte globale projektübergreifende Information (Pfade, Fehler-IDs, Nachrichten usw.) immer nützlich ist.

Wenn Sie ein Tool wie trac planen oder verwenden, das in SVN integriert ist, ist es sinnvoller, ein Repo pro Projekt zu verwenden.

Ähnlich wie bei Blades Vorschlag zum Freigeben von Dateien ist hier eine etwas einfachere und dennoch weniger flexible Lösung. Ich richte unsere so ein:

• / var / svn /
• / var / svn / bin
• / var / svn / repository_files
• / var / svn / svnroot
• / var / svn / svnroot / repos1
• / var / svn / svnroot / repos2
• ...

In "bin" behalte ich ein Skript namens svn-create.sh, das die gesamte Einrichtungsarbeit zum Erstellen eines leeren Repositorys erledigt. Ich behalte dort auch das Backup-Skript.

In "repository_files" behalte ich allgemeine "conf" - und "hooks" -Verzeichnisse, zu denen alle Repositorys sym-Links haben. Dann gibt es nur einen Satz von Dateien. Dies verhindert jedoch den granularen Zugriff pro Projekt, ohne die Links zu unterbrechen. Das war kein Problem, wo ich das eingerichtet habe.

Zuletzt halte ich das Hauptverzeichnis / var / svn unter Quellcodeverwaltung und ignoriere alles in svnroot. Auf diese Weise unterliegen auch die Repository-Dateien und -Skripte der Quellcodeverwaltung.

#!/bin/bash

# Usage:
# svn-create.sh repository_name

# This will:
# - create a new repository
# - link the necessary commit scripts
# - setup permissions
# - create and commit the initial directory structure
# - clean up after itself

if [ "empty" = ${1}"empty" ] ; then
  echo "Usage:"
  echo "    ${0} repository_name"
  exit
fi

SVN_HOME=/svn
SVN_ROOT=${SVN_HOME}/svnroot
SVN_COMMON_FILES=${SVN_HOME}/repository_files
NEW_DIR=${SVN_ROOT}/${1}
TMP_DIR=/tmp/${1}_$$

echo "Creating repository: ${1}"

# Create the repository
svnadmin create ${NEW_DIR}

# Copy/Link the hook scripts
cd ${NEW_DIR}
rm -rf hooks
ln -s ${SVN_COMMON_FILES}/hooks hooks

# Setup the user configuration
cd ${NEW_DIR}
rm -rf conf
ln -s ${SVN_COMMON_FILES}/conf conf

# Checkout the newly created project
svn co file://${NEW_DIR} ${TMP_DIR}

# Create the initial directory structure
cd ${TMP_DIR}
mkdir trunk
mkdir tags
mkdir branches

# Schedule the directories addition to the repository
svn add trunk tags branches

# Check in the changes
svn ci -m "Initial Setup"

# Delete the temporary working copy
cd /
rm -rf ${TMP_DIR}

# That's it!
echo "Repository ${1} created. (most likely)"

Ähnlich wie bei Mlambie, ein einzelnes Repo zu verwenden, ging die Ordnerstruktur jedoch etwas weiter, um einfach auf bestimmte Projekttypen zu zoomen - Web-HTML-basierte Projekte vs. CS (C #) vs. SQL (SQL-Skripte zum Erstellen / Ausführen) vs. XYZ ( Domain-spezifische Sprachen wie afl (AmiBroker Formula Language) oder ts (TradeStation)):

/<src|lib>/<app-settings|afl|cs|js|iphone|sql|ts|web>/<ClientName>/<ProjectName>/<branches|tags>

Beachten Sie, dass ich Trunk in Zweigen habe, da ich ihn als Standardzweig behandle. Manchmal ist der einzige Schmerz, wenn Sie schnell ein anderes Projekt erstellen möchten, müssen Sie die Struktur ProjectName / branch | tags erstellen. Ich verwende App-Einstellungen einfach als Ort, um bestimmte Apps-Einstellungsdateien im Repo so einfach für andere gemeinsam nutzbar zu machen (und ersetze ClientName durch VendorName und ProjectName durch AppName in dieser Ordnerstruktur; und die Zweige | -Tags können nützlich sein, um Einstellungen für verschiedene Hauptfächer zu kennzeichnen auch Versionen von Herstellerprodukten).

Willkommen zu allen Kommentaren zu meiner Struktur - ich habe sie kürzlich geändert und bin bisher ziemlich glücklich, finde es aber manchmal mühsam, Branch | Tags-Strukturen pro Projekt zu pflegen - insbesondere, wenn es sich bei dem Projekt lediglich um ein Projekt handelt, das einfach zum Unit-Test eines anderen Projekts eingerichtet wurde.

Mein Vorschlag ist einer. Wenn Sie nicht unterschiedliche Benutzer haben, die auf jeden zugreifen, würde ich sagen, verwenden Sie mehrere.

Aber auch das ist kein guter Grund, mehrere zu verwenden.