Wie das Sprichwort besagt, gibt es nichts zum Nulltarif. Obwohl einige Dienste kostenlose private Subversion-Repositorien anbieten ( RiouxSVN , Sprungschlaufen usw.), sind diese in der Regel mit erheblichen Einschränkungen verbunden (entweder in Bezug auf die maximale Speichergröße oder die Anzahl der Benutzer, die auf das Repository zugreifen dürfen).
Im Grunde genommen läuft die Entscheidung darauf hinaus, ob Sie für ein vollständig verwaltetes und vorkonfiguriertes Subversion-Repository bezahlen (wie es beispielsweise von Wolkenschmiede o Bohnenstange ) oder ob Sie stattdessen für einen Infrastructure-as-a-Service (IaaS)-Cloud-Hosting-Dienst bezahlen (z. B. Rechenmaschine , AWS EC2 o Azurblau ) für eine virtuelle Maschine und übernehmen die Verantwortung für die Einrichtung des Subversion-Servers auf dieser virtuellen Maschineninstanz, übernehmen die Verantwortung für die Sicherheit und die Zugriffskontrolle dieser virtuellen Maschine und übernehmen die Verantwortung für den Domainnamen, die SSL-Zertifikate usw., die für den Fernzugriff auf diesen Server über das Internet verwendet werden. Es gibt auch eine Zwischenlösung, z. B. die Verwendung eines Abbilds/einer Konfiguration einer virtuellen Maschine eines Drittanbieters, die speziell für den Betrieb eines Subversion-Servers bei einem Cloud-Hosting-Anbieter bestimmt ist (wie z. B. bei der Verwendung des Cloud Launcher Subversion-Abbild zur Verfügung gestellt von Bitnami die die Bereitstellung, Wartung, Implementierung usw. von Subversion auf Compute Engine vereinfacht).
Bei all den verschiedenen Optionen/Ansätzen besteht der Kompromiss in der Regel aus Kosten und Aufwand; die Nutzung eines Cloud-Hosting-Anbieters und die Einrichtung eines Subversion-Servers durch Sie selbst ist aufwändiger, aber auch billiger. Wenn Sie einen Subversion-Server auf Compute Engine oder in einer VPC auf AWS bereitstellen und die Maschine nicht dem öffentlichen Internet aussetzen (so dass nur andere VMs in diesem Subnetz/VPC darauf zugreifen können), dann ist das Risiko relativ gering. Sobald Sie ihn jedoch so konfigurieren, dass er für das öffentliche Internet zugänglich ist, müssen Sie abwägen, ob Sie dieses Risiko und die Sicherheit der VM lieber selbst tragen wollen oder ob Sie für die Verwaltung dieses Risikos durch einen Dritten extra bezahlen. Ein weiterer Kompromiss, den Sie in Betracht ziehen sollten, ist die Flexibilität; der Do-it-yourself-Ansatz erlaubt Ihnen möglicherweise, Elemente des Verhaltens des Subversion-Servers anzupassen (z. B. Details der Benutzerautorisierung), die Sie bei einer vollständig gehosteten Option nicht so leicht kontrollieren können. Ein weiterer Kompromiss, den man in Betracht ziehen sollte, sind die Kosten und die Einfachheit der Sicherung des Repositorys; wenn es sich lohnt, es in einem Repository zu speichern, lohnt es sich wahrscheinlich auch, es zu sichern; bei einigen Lösungen ist die Sicherung einfacher/günstiger als bei anderen.
