Subversion hat mehrere Typen Server:Welcher Subversion Server Typ ist der beste?
Welches ist das Beste für ein kleines Linux-System (ein bis zwei Benutzer)?
http befassen:
https:
svn:
svn + ssh
Ich mag sliksvn läuft als ein Dienst in Windows, 2 Minuten Setup und dann vergessen Sie es.
Es kommt auch mit den Client-Tools, sondern auch Tortoise herunterladen.
Ich habe immer XInetD und HTTP verwendet. HTTP hatte auch WebDAV, so dass ich die Quelle online durchsuchen konnte, wenn ich wollte (oder Sie können ein VPN anfordern, wenn Sie eine Verschlüsselung und ein Dark-Net-Typ-Ding wollten).
Es hängt wirklich davon ab, welche Einschränkungen (wenn überhaupt) Sie unterstehen.
Wird es nur in einem LAN sein? Benötigen Sie Zugriff außerhalb Ihres LANs? Wenn ja, haben Sie ein VPN? Haben Sie eine statische IP-Adresse und dürfen Ports weiterleiten?
Wenn Sie keine Einschränkung haben, würde ich vorschlagen, mit xinetd gehen (wenn Sie xientd installiert haben, Daemon, wenn Sie nicht) und dann (wenn Sie Remote-Zugriff benötigen) http-basierten Server verwenden, wenn Sie Fernzugriff erforderlich (Sie können auch mit HTTPS verschlüsseln, wenn Sie nicht wollen, dass un/pw-Text übergesendet wird).
Die meisten anderen Optionen sind mehr Aufwand mit weniger Nutzen.
Es ist ein SVN Repo - Sie können immer Ihre Taschen packen und Dinge ändern, wenn Sie es nicht mögen.
1 dieser Optionen ist definitiv eine "schlimmste": Dateizugriff. Verwenden Sie es nicht, verwenden Sie stattdessen eine der serverbasierten Methoden.
Ob HTTP oder Svnserve verwendet wird, ist jedoch eine Frage der Präferenz. Tatsächlich können Sie beide gleichzeitig verwenden, die Schreibsperre des Repos stellt sicher, dass Sie nichts beschädigen, wenn Sie eines verwenden und dann ein anderes verwenden.
Meine Präferenz ist einfach Apache zu verwenden - http ist mehr Firewall und Internet-freundlich, es ist auch einfacher, in ldap oder andere Authentifizierungsmechanismen einzuhaken, und Sie erhalten Funktionen wie WebDAV auch. Die Leistung ist möglicherweise weniger als svnserve, aber es ist nicht besonders auffällig (die Übertragung von Daten über das Netzwerk macht den Großteil der Leistungsprobleme)
Wenn Sie Sicherheit für Dateiübertragungen benötigen, dann Svnserve + SSH, oder Apache über https ist deine Wahl.
Wenn Sie den Server nur auf dem lokalen Computer verwenden und Unix-Berechtigungen verstehen, ist die Verwendung von file: // urls schnell, einfach und sicher. Ebenso, wenn Sie Unix-Berechtigungen und SSH verstehen und auf Remote-Zugriff zugreifen müssen, funktioniert SSH großartig. Während ich sehe, dass jemand anderes es als "schlimmste" bezeichnet, bin ich mir ziemlich sicher, dass dies einfach auf die Notwendigkeit zurückzuführen ist, Unix-Berechtigungen zu verstehen.
Wenn Sie Unix-Berechtigungen nicht mögen oder verstehen, müssen Sie mit Svnserve oder http gehen. Ich würde wahrscheinlich wählen, es in xinetd persönlich zu führen.
Schließlich, wenn Sie Firewall- oder Proxy-Probleme haben, müssen Sie möglicherweise http in Betracht ziehen. Es ist viel komplizierter, und ich glaube nicht, dass Sie die Vorteile sehen werden, also würde ich es zuletzt auf Ihre Liste setzen.
würde ich die http Option empfehlen, da ich zur Zeit svn+ssh bin mit und es erscheint das rothaarige Stiefkind der verfügbaren Protokolle zu sein: für svn+ssh 3rd-Party-Tool-Unterstützung ist durchweg schlechter als es für http ist.
Auschecken FLOSS Weekly Episode 28. Greg Stein ist einer der Erfinder des WebDAV-Protokolls für SVN und diskutiert die Kompromisse. Mein Vorteil ist, dass SVN: ist schneller, aber die http/Webdav-Implementierung ist für fast alle Zwecke gut.
Ich war verantwortlich für die Verwaltung sowohl Svnserve und Apache + SVN für meine Entwicklungsteams, und ich bevorzuge die http-basierte Lösung für ihre Flexibilität. Ich weiß fast nichts über Systemadministration, ich bin schließlich ein Software-Typ, und ich mochte es, Authentifizierung und Autorisierung an Apache weitergeben zu können.
Beide Zinken der Teams waren etwa 10 ~ 15 Leute und beide Methoden funktionierten gleich gut. Wenn Sie eine zukünftige Erweiterung planen, sollten Sie die http-basierte Lösung in Erwägung ziehen. Es ist genauso einfach zu konfigurieren wie svnserve, und wenn Sie den Server nicht dem Internet aussetzen, müssen Sie sich nicht allzu viele Gedanken über das Sichern und Verwalten von Apache machen.
Als Benutzer von SVN bevorzuge ich die http-basierte Integration mit Apache. Ich mag es, das Repository mit meinem Webbrowser durchsuchen zu können.
Um die Administration und Sicherheit zu vereinfachen, verwenden wir svn + ssh für alles, was einen Commit-Zugriff erfordert. Wir haben einen HTTP-basierten Zugriff für den anonymen (schreibgeschützten) Zugriff auf Open-Source-Code eingerichtet, und das ist viel schneller. Das Problem mit svn + ssh ist, dass es eine ssh-Verbindung und ein ganz neues svnserve für jeden Benutzer für jede Operation starten muss, was nach einiger Zeit ziemlich langsam werden kann.
Also, würde ich empfehlen:
Ich bin neugierig, warum nicht FSFS ?? Wichtige Informationen - Ich verwalte Windows-Systeme.
Ich habe viele Projekte mit SVN gemacht und fast alle von ihnen lief von FSFS. Das größte Repository war rund 70 GB (extrem), die größte Menge an Repositories war rund 700.
Wir hatten nie Probleme, obwohl wir es auf Windows, NetApp und vielen anderen Speichersystemen hosten. Die meiste Zeit, als ich fragte, warum ich das FSFS-Problem NICHT nutze, war, dass die Leute einfach nicht darauf vertrauten.
Vorteile:
Disa orteile:
Martin
zusammengefasst Ich kann mir vorstellen, es wäre wert für ein großes System zu betrachten. Aber für den kleinen Maßstab wäre es übertrieben – PiedPiper
Nizza Zusammenfassung. http und https sollten in Subversion 1.7 viel schneller werden, wo serf (mit besserer Parallelität) zum Standard wird und die neue Subversion HTTPv2-Implementierung viele Roundtrips der aktuellen http-Implementierung reduziert. –
thanx bert, für Hinweis darauf, jedoch svn1.7 ist weit voraus (Release Ende des Jahres?), So dass ich nur die Fakten in 1.6 –