La scelta di un server Subversion

Question

Dopo aver scelto Apache Subversion per le mie esigenze di controllo delle versioni (e AnkhSVN/TortoiseSVN per i miei clienti Subversion primari). Ora sto provando a scegliere il server SVN per fornire l'accesso remoto ai repository SVN. Ho guardato un paio di loro:

• CollabNet Subversion Edge
• VisualSVN Server

Ho installato ciascuno in una macchina virtuale per provare a giocare, ma non ho trovato abbastanza per differenziare la maggior parte di loro in misura sufficiente a scegli uno specifico. Ora ho alcune cose che devo decidere.

1. protocollo
2. fornitore
3. SSL

1. Ho letto che HTTP è molto più lento rispetto al protocollo SVN. Mentre i miei progetti non sono generalmente troppo grandi (in realtà solo l'importazione iniziale è la parte che richiede tempo), voglio ottenere i benefici delle prestazioni di SVN, così come evitare che i miei log HTTP vengano inondati di voci SVN (che io non è stato ancora possibile effettuare la segregazione in un file LOG seprato).

Mi piace l'interfaccia Web che utilizza un modulo Apache o VisualSVN. Non ho davvero bisogno di fornire le mie cose ad altri (o anche a me stesso lontano dal mio sistema), quindi non è critico, ma certamente consente l'espandibilità.

2. Dopo aver scelto un protocollo (supponendo che ho di scegliere); Ho bisogno di aiuto per decidere quale venditore usare. Inizialmente ho usato il modulo Apache dalla distribuzione Tigris. Da allora l'ho rimosso (beh, solo disabilitato), e attualmente sto usando VisualSVN (che è HTTP e quindi lento). Ho visto persone approvare Sharp e Silk ma sembrano essere più piccole, indie distro.
Collabnet, d'altra parte, sembra essere più elaborato del necessario. Fondamentalmente, a meno che non riesca a convincere per uno di questi, sto principalmente cercando di scegliere tra il Tigris ufficiale e VisualSVN.

3. Ho anche cercato di fare in giro con SSL senza molto successo (Non posso permettermi una vera e propria CA, quindi sto usando un CERT auto-firmato a VisualSVN). Sarei felice di usare SVN + SSH/HTTPS, ma se lo sto usando sul mio sistema, allora non è necessario, e se lo uso esternamente, allora il mio certificato autofirmato non sarà di aiuto.

Suppongo che potrei anche utilizzare un repository locale; Penserei che sarebbe il più veloce. Tuttavia preferirei una soluzione più formale nel caso in cui mi espandessi. (Ho considerato solo utilizzando il client TortiseSVN per fare il lavoro del server in locale.)

Quindi, in sintesi, ho bisogno di qualche consiglio su quale server (s ?) Da usare.Sarebbe bello se VisualSVN fosse in grado di fornire un'interfaccia HTTP per uso web, ma anche servire su un protocollo SVN per l'utilizzo nei client, preferibilmente con l'opzione di SSL su ciascuno. È possibile? Sarebbe troppo lavoro (voglio davvero tornare a lavorare sui miei progetti piuttosto che su tutto questo meta-lavoro).

Grazie mille.

Modifica

ho pensato di dare un po 'di informazioni sulle circostanze di chiarire le cose.

• (al momento) unico sistema (più vecchio P4, Finestre, 1 GB SDRAM)
• (Attualmente) singolo sviluppatore (ME)
• (Attualmente) progetti relativamente piccoli (< 2MB)
• progetti Innumerevoli (> 100 app singole, giochi, librerie, siti Web, ecc.)
• Esterni richiesti (in particolare la mia libreria personale, l'intestazione di terze parti, Boost, ecc.)
• ? hmm, che altro ...

Answer 1

Edit: Dopo aver letto le altre risposte qui, c'è una cosa che ho pensato che avrei dovuto parlare. Se provi un server, i repository che gli chiedi di servire non saranno diversi dai repository a cui chiederai un altro tipo di server.

In altre parole, se si decide di provare un server ora, è possibile passare a un altro tipo di server in un secondo momento, senza perdere i repository. Ovviamente, le copie funzionanti e tutti i riferimenti esterni assoluti che hai creato nei tuoi progetti, dovranno cambiare, ma puoi mantenere i tuoi repository con la cronologia e tutto il resto.

---

ho installato VisualSVN Server quando è stato annunciato, ed era abbastanza soddisfatto, per un po '.

Tuttavia, i problemi di velocità mi hanno indotto a passare al server svnserve principale che viene fornito come parte del pacchetto della riga di comando di Subversion.

Il problema principale è che sto lavorando con .NET e ho scelto di aggiungere diversi riferimenti esterni a Subversion ai miei progetti.

Innanzitutto, e soprattutto, ogni progetto che faccio nella mia libreria di classe è firmato dalla mia chiave. In secondo luogo, le librerie esterne di terze parti, come SQLite e NUnit, sono state aggiunte come riferimenti esterni.

Ogni progetto ha i propri riferimenti esterni. L'ho fatto per essere in grado di creare un nuovo progetto applicativo, e quindi creare nuovi riferimenti esterni alle parti della mia libreria di classi di cui avevo bisogno e che quei riferimenti fossero completi. Se la mia soluzione di libreria di classi in .NET aveva un riferimento esterno per il file della chiave di firma e quel file non era disponibile come parte di un singolo progetto, ma si trovava su disco al di fuori di tutti i progetti, ma locale alla mia soluzione, sarebbe non ha funzionato

Quindi, la mia soluzione di libreria di classi contiene alcuni 15-20 progetti, ognuno con almeno un riferimento esterno alla chiave di firma, tutti i miei progetti di dati hanno riferimenti esterni alla libreria SQLite e la libreria di test di unità con 4-5 riferimenti esterni.

Il risultato è stato che un singolo aggiornamento a livello di soluzione, anche se avevo già tutti i file più recenti, le directory, tutto, è durato circa 2 minuti. Ogni singolo riferimento esterno richiedeva tra 10 e 20 secondi per completare, solo per verificare che avessi la revisione di cui avevo bisogno.

Quando sono passato a svnserve, quei 2 minuti sono stati ridotti a circa 3 secondi. Questo è il traffico locale, quindi ovviamente questo sarà diverso su Internet. Il problema è che quei 2 minuti erano anche traffico locale.

Così, mentre mi è piaciuto molto l'interfaccia VisualSVN Server mi ha fornito, compresa la possibilità di facilmente impostare i diritti di accesso e degli utenti, la velocità che il modulo server Apache mi ha fornito era assolutamente orribile in confronto con quello che svnserve e il protocollo Subversion nativo lo fa.

Nota che da allora ho installato un server Apache separato, ho navigato su molti file di configurazione e ho impostato Subversion con Apache diverso dal server VisualSVN, giusto per assicurarmi che non fosse solo VisualSVN, e ho ha confermato che la velocità osservata non era opera del team VisualSVN. Sembra che il protocollo HTTP oi moduli Apache non siano così veloci.

Il mio consiglio è di andare con il server svnserve principale, se possibile. Potrebbe volerci un po 'di lavoro per conoscere i file di configurazione per l'autorizzazione e simili, ma il fattore di irritazione da solo (cioè nessuna irritazione per eccesso di velocità) sarà più che probabile che supererà quello.

Answer 2

Sto usando CollabNet a casa e al lavoro. È andato tutto bene - nessuna lamentela con le prestazioni.

Answer 3

Re access speed: Ho visto un server SVN di Apache che necessita di un aggiornamento hardware. Mi sembra di ricordare che principalmente la mancanza di memoria ha rallentato i numerosi processi di Apache che competevano per le risorse della macchina. Ma erano 20 gli sviluppatori che collaboravano a un progetto con un albero da 20 GB controllato (molti binari, che spesso cambiavano). E l'aggiornamento a un server moderatamente attrezzato ha risolto il problema.

Inoltre, in questo stesso progetto, ho dovuto imparare che SVN su un file system ext3 su Linux era a un ordine di grandezza più veloce rispetto a NTFS in Windows. Contrassegna quello: Il Linux in una macchina virtuale in esecuzione su Windows ha impiegato un decimo di tempo per un aggiornamento in concorrenza con la casella Windows su cui la VM era in esecuzione su. (Abbiamo sempre voluto provare il driver OS ext3 per Windows e vedere se questo non avrebbe reso SVN più veloce su Windows rispetto al suo FS nativo. Comunque, ho lasciato il progetto prima di provarci.)

Comunque, non è come quello per cui tu decidi di essere gettato nella pietra per l'eternità. Puoi provare una cosa, testarla accuratamente in un progetto reale e passare a un altro server e protocollo in seguito. (C'è anche un comando SVN per passare l'URL di un albero estratto Questo è possibile utilizzare per cambiare il protocollo, senza dover controllare tutto daccapo..)

Ecco quello che vorrei prendere in considerazione per decidere sul protocollo: se si dispone di un'infrastruttura AD o LDAP funzionante che si desidera sfruttare per l'accesso in SVN, provare una delle opzioni del protocollo http/https:. Se non hai questo, e non ne avrai bisogno, e stai facendo il login con mezzi propri di SVN, perché non usare la velocità fornita dal protocollo svn:?

Non ho mai visto un repository SVN a cui le persone hanno utilizzato l'accesso WebDAV. IME vogliono sempre avere la cronologia quando accedono per web (WebDAV non fornisce questo, AFAIK), quindi hanno usato uno dei frontend Web per SVN.Non ho mai controllato, ma presumo che cose come ViewVC e simili non si preoccupino del protocollo che usano per accedere al repository.

Per quanto riguarda la distribuzione che si desidera utilizzare, penso che sia principalmente dovuta alle preferenze personali, poiché il codice sottostante è lo stesso comunque. Preferisco i download che non devo registrare e le distribuzioni che puntano esplicitamente alla piattaforma su cui voglio installarli. Ma probabilmente sono solo io.

Tuttavia, c'è un fatto difficile da considerare se il repository è accessibile da Internet: quando il progetto SVN ha fatto una nuova versione puntinata, per quanto tempo, in passato, ha preso le diverse distribuzioni per recuperare . Poiché queste potrebbero essere correzioni di sicurezza, potresti preferire quelle che, di solito, forniscono le correzioni più velocemente.

Answer 4

Forniamo i nostri repository SVN utilizzando HTTP fornito da Apache in esecuzione in CentOS 5.3 all'interno di una macchina virtuale XEN.

Osserverei che eseguendo un commit o un checkout su un file di grandi dimensioni, il file viene trasferito alla velocità di rete vicina. Durante il check-out o l'esecuzione di un numero elevato di file di piccole dimensioni, il sovraccarico delle richieste HTTP è molto più evidente.

Rispetto ai tempi nel codice di compilazione, SubVersion non è visto come un collo di bottiglia all'interno dell'azienda.

(Questa è la mia esperienza con un team di 10 sviluppatori)