Auswahl eines Subversion-Servers

Question

Nach der Auswahl Apache Subversion für meinen Bedarf an Versionskontrolle (und AnkhSVN / TortoiseSVN für meine primären Subversion-Clients). Jetzt versuche ich, einen SVN-Server auszuwählen, der den Fernzugriff auf SVN-Repositories ermöglicht. Ich habe mir ein paar von ihnen angesehen:

• CollabNet Subversion Edge
• VisualSVN-Server

Ich habe jede in einer VM installiert, um sie auszuprobieren, aber ich habe nicht genug gefunden, um die meisten von ihnen ausreichend zu unterscheiden, um eine bestimmte auszuwählen. Jetzt habe ich ein paar Dinge, die ich auf entscheiden müssen.

1. Protokoll
2. Anbieter
3. SSL

1. Ich habe gelesen, dass HTTP viel Langsamer als das SVN-Protokoll. Obwohl meine Projekte im Allgemeinen nicht allzu groß sind (eigentlich ist nur der anfängliche Import der zeitaufwändige Teil), möchte ich die Leistungsvorteile von SVN nutzen und vermeiden, dass meine HTTP-Protokolle mit SVN-Einträgen überflutet werden (die ich bis jetzt noch nicht in eine separate LOG-Datei auslagern konnte) .

Ich mag jedoch die Webschnittstelle, die die Verwendung eines Apache-Moduls oder VisualSVN bietet. Ich muss meine Sachen nicht wirklich anderen zur Verfügung stellen (oder sogar mir selbst außerhalb meines Systems), also ist es nicht kritisch aber es ist sicherlich ausbaufähig.

2. Nach der Auswahl eines Protokolls (unter der Annahme, dass I haben zu wählen); ich brauche Hilfe bei der Entscheidung, welchen Anbieter ich verwenden soll. Ursprünglich habe ich das Apache-Modul aus der Tigris-Distribution verwendet. Ich habe es inzwischen entfernt (na ja, nur deaktiviert) und verwende derzeit VisualSVN (das HTTP und damit langsam ist). Ich habe gesehen, dass Leute Sharp und Silk empfohlen haben, aber das scheinen kleinere Indie-Distributionen zu sein.
Collabnet hingegen scheint aufwändiger zu sein, als ich es brauche. Im Grunde genommen, es sei denn, ich kann für eine von ihnen überzeugt werden, ich bin vor allem nur versuchen, zwischen dem offiziellen Tigris und VisualSVN zu wählen.

3. Ich habe auch versucht, mit SSL herumzuspielen, ohne viel Erfolg (ich kann mir keine echte CA leisten, also verwende ich ein selbstsigniertes Zertifikat in VisualSVN). Ich würde gerne SVN+SSH/HTTPS verwenden, aber wenn ich es auf meinem eigenen System verwende, ist es nicht notwendig, und wenn ich es extern verwende, hilft mir mein selbstsigniertes Zertifikat nicht.

Ich nehme an, dass ich sogar ein lokales Repository verwenden könnte; ich würde denken, dass dies am schnellsten wäre. Allerdings würde ich eine formellere Lösung für den Fall bevorzugen, dass ich expandiere. (Ich habe überlegt, einfach den TortiseSVN-Client zu verwenden, um die Arbeit des Servers lokal zu erledigen).

Zusammenfassend kann ich also sagen, dass ich einen Rat brauche, welcher Server( s ?) zu verwenden. Es wäre großartig, wenn ich VisualSVN dazu bringen könnte, eine HTTP-Schnittstelle für die Webnutzung bereitzustellen, aber auch ein SVN-Protokoll für die Nutzung in den Clients zu verwenden, vorzugsweise mit der Option von SSL auf jedem. Ist das möglich? Wäre es zu viel Arbeit (ich möchte wirklich wieder an meinen Projekten arbeiten und nicht an dieser ganzen Meta-Arbeit).

Herzlichen Dank.

bearbeiten

Ich dachte, ich sollte ein paar Informationen über meine Umstände geben, um die Dinge zu klären.

• (Derzeit) Einzelsystem, (älterer P4, Windows, 1GB SDRAM)
• (Derzeit) Einzelner Entwickler (ich)
• (Derzeit) Relativ kleine Projekte (<2MB)
• Unzählige Projekte (>100 einzelne Anwendungen, Spiele, Bibliotheken, Websites usw.)
• Externals erforderlich (insbesondere meine eigene Bibliothek sowie Header von Drittanbietern, Boost usw.)
• ? hmm, was sonst

Answer 1

bearbeiten : Nachdem ich die anderen Antworten hier gelesen habe, möchte ich noch eine Sache erwähnen. Wenn Sie einen Server ausprobieren, unterscheiden sich die Repositories, die Sie ihm zur Verfügung stellen, nicht von den Repositories, die Sie einem anderen Servertyp zur Verfügung stellen.

Mit anderen Worten: Wenn Sie sich jetzt für einen Server entscheiden, können Sie später zu einem anderen Servertyp wechseln, ohne Ihre Repositories zu verlieren. Natürlich müssen die Arbeitskopien und alle absoluten externen Referenzen, die Sie in Ihren Projekten erstellt haben, geändert werden, aber Sie können Ihre Repositorys mitsamt der Historie und allem anderen behalten.

---

Ich installierte VisualSVN-Server als es angekündigt wurde, und war eine Zeit lang recht zufrieden damit.

Aufgrund von Geschwindigkeitsproblemen wechselte ich jedoch zum svnserve-Hauptserver, der als Teil des Subversion-Befehlszeilenpakets mitgeliefert wird.

Das Hauptproblem besteht darin, dass ich mit .NET arbeite und mehrere externe Subversion-Referenzen zu meinen Projekten hinzugefügt habe.

Zunächst einmal ist jedes Projekt, das ich in meiner Klassenbibliothek mache, mit meinem Schlüssel signiert. Zweitens: Externe Bibliotheken von Drittanbietern, wie SQLite と NUnit wurden als externe Referenzen hinzugefügt.

Jedes Projekt hatte seine eigenen externen Referenzen. Ich tat dies, um ein neues Anwendungsprojekt zu erstellen und dann neue externe Verweise auf die Teile meiner Klassenbibliothek zu erstellen, die ich benötigte, und damit diese Verweise vollständig waren. Hätte meine Klassenbibliothekslösung in .NET einen externen Verweis für die Signierschlüsseldatei, und diese Datei wäre nicht als Teil eines einzelnen Projekts verfügbar gewesen, sondern hätte sich auf der Festplatte außerhalb aller Projekte, aber lokal in meiner Lösung befunden, hätte das nicht funktioniert.

Meine Klassenbibliothekslösung enthält also etwa 15-20 Projekte, von denen jedes mindestens einen externen Verweis auf den Signierschlüssel hat, alle meine Datenprojekte haben externe Verweise auf die SQLite-Bibliothek, und die Unit-Test-Bibliothek hat 4-5 externe Verweise.

Das Ergebnis war, dass eine einzige Aktualisierung auf Lösungsebene, selbst wenn ich bereits alle aktuellen Dateien, Verzeichnisse und alles andere hatte, etwa 2 Minuten in Anspruch nahm. Für jeden einzelnen externen Verweis benötigte ich zwischen 10 und 20 Sekunden, nur um zu überprüfen, ob ich die benötigte Version hatte.

Als ich zu svnserve wechselte, wurden diese 2 Minuten auf etwa 3 Sekunden reduziert. Dabei handelt es sich allerdings um lokalen Datenverkehr, so dass dies im Internet natürlich anders sein wird. Das Problem ist, dass diese 2 Minuten auch lokaler Verkehr waren.

Obwohl ich die Schnittstelle, die VisualSVN Server mir zur Verfügung gestellt hat, absolut geliebt habe, einschließlich der Möglichkeit, die einfach Zugriffsrechte und Benutzer einzurichten, war die Geschwindigkeit, die mir das Apache-Servermodul bot, im Vergleich zu dem, was svnserve und das native Subversion-Protokoll leisten, absolut schrecklich.

Ich habe seitdem einen separaten Apache-Server installiert, mich durch viele Konfigurationsdateien gewühlt und Subversion mit Apache auf einem anderen als dem VisualSVN-Server eingerichtet, nur um sicherzugehen, dass es nicht nur an VisualSVN lag, und ich habe bestätigt, dass die von mir beobachtete Geschwindigkeit nicht das Werk des VisualSVN-Teams war. Es scheint, dass das HTTP-Protokoll oder die Apache-Module einfach nicht so schnell sind.

Mein Rat ist, wenn möglich, den Hauptserver von svnserve zu verwenden. Es mag zwar etwas Arbeit erfordern, sich mit den Konfigurationsdateien für die Autorisierung und dergleichen vertraut zu machen, aber allein der Irritationsfaktor (d.h. keine Irritation über die Geschwindigkeit) wird das mehr als aufwiegen.

Answer 2

Zur Zugriffsgeschwindigkeit: Ich habe einen Apache https: SVN Sever benötigt ein Hardware-Update. Ich glaube mich zu erinnern, dass es vor allem am mangelnden Speicher lag, der die zahlreichen Apache-Prozesse verlangsamte, die um die Ressourcen des Rechners konkurrierten. Aber das waren 20 Entwickler, die an einem Projekt mit einem ausgecheckten Baum von 20 GB arbeiteten (mit vielen Binärdateien darin, die sich oft änderten). Und das Update auf einen mäßig ausgestatteten Server löste das Problem.

Außerdem musste ich in diesem Projekt lernen, dass SVN auf einem ext3 FS unter Linux mindestens eine Größenordnung schneller war als auf NTFS unter Windows. Merken Sie sich das: Das Linux in einer virtuellen Maschine, die unter Windows läuft, benötigte nur ein Zehntel der Zeit für ein Update im Vergleich zu dem Windows-System, auf dem die VM lief . (Wir wollten schon immer den ext3-Treiber für Windows ausprobieren, um zu sehen, ob SVN dadurch unter Windows nicht schneller wird als das native FS. Ich habe das Projekt jedoch verlassen, bevor wir überhaupt dazu kamen, es zu versuchen.)

Es ist ja nicht so, dass das, wofür man sich entscheidet, für die Ewigkeit in Stein gemeißelt ist. Sie können eine Sache ausprobieren, sie in einem echten Projekt gründlich testen und später zu einem anderen Server und Protokoll wechseln. (Es gibt sogar einen SVN-Befehl, um die URL zu wechseln eines ausgecheckten Baumes . Damit können Sie das Protokoll wechseln, ohne alles neu überprüfen zu müssen).

Hier ist, was ich bei der Entscheidung über das Protokoll berücksichtigen würde: Wenn Sie eine funktionierende AD- oder LDAP-Infrastruktur haben, die Sie für die Anmeldung in SVN nutzen möchten, versuchen Sie eine der http / https: Protokoll-Optionen. Wenn Sie das nicht haben und es auch nicht brauchen, und wenn Sie sich mit den SVN-eigenen Mitteln anmelden können, warum nutzen Sie dann nicht die Geschwindigkeit, die das Programm svn: Protokoll?

Ich habe noch nie ein SVN-Repository gesehen, auf das man mit WebDAV zugegriffen hat. IME wollen sie immer den Verlauf haben, wenn sie über das Web zugreifen (WebDAV bietet dies nicht, AFAIK), so dass sie eine der Web-Frontends für SVN verwendet. Ich habe es nie überprüft, aber ich nehme an, dass Dinge wie AnsichtVC und dergleichen ist es egal, welches Protokoll sie für den Zugriff auf das Repo verwenden.

Was die Frage angeht, welche Distribution Sie verwenden wollen - ich denke, das ist hauptsächlich eine Frage der persönlichen Vorlieben, da der Code darunter sowieso der gleiche ist. Ich bevorzuge Downloads, für die ich mich nicht registrieren muss und Distributionen, die explizit auf die Plattform abzielen, auf der ich sie installieren möchte. Aber das ist wahrscheinlich nur meine Meinung.

Es gibt jedoch eine harte Tatsache, die Sie berücksichtigen sollten, wenn Ihr Repository über das Internet zugänglich ist: Wenn das SVN-Projekt ein neues Dot-Release veröffentlicht hat, wie lange haben die verschiedenen Distributionen in der Vergangenheit gebraucht, um den Rückstand aufzuholen. Da es sich dabei um Sicherheitskorrekturen handeln könnte, sollten Sie die Distributionen bevorzugen, die die Korrekturen in der Regel schneller bereitstellen.

Answer 3

Wir stellen unsere SVN-Repositories über HTTP bereit, das von Apache unter CentOS 5.3 in einer virtuellen XEN-Maschine bereitgestellt wird.

Ich habe festgestellt, dass die Übertragung einer großen Datei bei einer Übergabe oder einem Auschecken fast mit Netzwerkgeschwindigkeit erfolgt. Beim Auschecken oder Übertragen einer großen Anzahl kleiner Dateien macht sich der Overhead der HTTP-Anfragen viel stärker bemerkbar.

Verglichen mit dem Zeitaufwand für die Kompilierung von Code wird SubVersion innerhalb des Unternehmens nicht als Engpass angesehen.

(Dies ist meine Erfahrung mit einem Team von 10 Entwicklern)

Answer 4

Ich verwende CollabNet zu Hause und bei der Arbeit. Es läuft gut - keine Beschwerden über die Leistung.