Come dice il proverbio, non c'è il pranzo gratis. Sebbene alcuni servizi offrano repository Subversion privati gratuiti (RiouxSVN, Springloops, ecc.), Questi in genere presentano limitazioni significative (in termini di dimensioni massime di archiviazione o numero di utenti che possono accedere al repository).
In realtà, la decisione si riduce a se si paga per un repository Subversion completamente gestito che è preconfigurato (come quello offerto da Cloud Forge o Beanstalk) o se, invece, si paga per un'infrastruttura-as-a- Servizio di hosting cloud (IaaS) di servizio (ad esempio Compute Engine, AWS EC2 o Azure) per una macchina virtuale e assumersi la responsabilità della configurazione del server Subversion su quell'istanza della macchina virtuale, assumersi la responsabilità della sicurezza e del controllo di accesso di tale macchina virtuale, e assumersi la responsabilità per il nome di dominio, i certificati SSL, ecc. che vengono utilizzati per accedere a quel server da remoto su Internet. Esiste anche un approccio intermedio, come l'utilizzo di un'immagine/configurazione di una macchina virtuale di terze parti specifica per l'esecuzione di un server Subversion su un provider di hosting cloud (come nel caso dell'utilizzo dello Cloud Launcher Subversion image fornito da Bitnami, che semplifica il provisioning , manutenzione, implementazione, ecc. di Subversion su Compute Engine).
Per tutte le diverse opzioni/approcci, il compromesso è in genere tra costi e problemi; l'utilizzo di un provider di hosting cloud e la creazione di un server Subversion da soli è più complicato ma anche più economico. C'è anche un compromesso in termini di rischio/sicurezza; se si distribuisce un server Subversion su Compute Engine o in un VPC su AWS e non si espone la macchina a Internet pubblica (in modo che sia accessibile solo ad altre macchine virtuali fornite in quella sottorete/VPC), il rischio è relativamente basso; tuttavia, una volta configurato per essere accessibile alla rete pubblica, è necessario considerare se si preferisce possedere tale rischio e la sicurezza della VM stessa, pagando un extra per consentire a una terza parte di gestire tale rischio. Un altro compromesso da considerare è la flessibilità; l'approccio fai-da-te può consentire di personalizzare gli elementi del comportamento del server Subversion (come i dettagli su come autorizza gli utenti) che potresti non essere in grado di controllare con facilità con un'opzione completamente ospitata. Infine, un altro compromesso da considerare sono i costi e la facilità di backup del repository; se vale la pena archiviare in un repository, probabilmente ne vale la pena anche il backup; alcune soluzioni rendono più semplice/economico il backup rispetto ad altri.
fonte
2010-03-28 01:53:17
Il tuo progetto è open source? –
no. è un progetto aziendale. qual è il modo migliore per questo tipo di progetti? svn privato? il problema è che non abbiamo un server (che potrebbe essere attivo e funzionante 24 * 7). qual è la soluzione migliore allora? –
LMAO al titolo attuale di "purblic ... server". È meraviglioso, e non ho intenzione di modificare il titolo per essere scritto correttamente. –