Dove dovrebbe essere un repository Subversion?

Question

Dovrebbe trovarsi sui server di sviluppo o su un server Subversion?

Suppongo che questo possa essere esteso a qualsiasi sistema di controllo versione client-server.

Answer 1

Il repository fisico deve trovarsi su un sistema stabile che ottiene backup regolari.

Generalmente, un server di sviluppo non si adatta a questa descrizione ... può essere accettabile collocare il server Apache sul server di sviluppo e ospitare i file in remoto su un server di file stabile, di backup (sebbene ci sia un numero di insidie ​​con questo approccio) se non si è in grado di ottenere risorse aggiuntive del server. Ospitarlo sul server dev può andare bene se hai un sistema di backup aggressivo per proteggere il tuo codice ...

Tieni presente che i server di sviluppo sono inclini a modifiche di configurazione, a essere spazzati via o in altro modo a farlo potrebbe prendere giù il tuo repo in un momento critico.

Answer 2

Conservo il mio sul server di sviluppo, che esegue anche Trac, Apache che ospita una copia aggiornata automaticamente del progetto JavaDocs e la piattaforma di build CI. Un progetto dovrebbe essere di proporzioni abbastanza epiche da richiedere un server Subversion dedicato.

Tuttavia, tieni presente che è molto importante eseguire il backup del repository Subversion su un'altra macchina in un'altra posizione: il tuo repository è la risorsa più preziosa!

Answer 3

Mi piace tenere il mio sul proprio server, solo perché a mio avviso è uno dei server più importanti in un'organizzazione e tenerlo sul proprio server aiuta gli amministratori a fare backup e altre attività di manutenzione. E poiché il server è quindi è importante che non si voglia che altri sviluppatori se ne vadano in giro in un modo che potrebbe comprometterlo per sbaglio.

Inoltre, se si dispone di un gruppo di sviluppatori e di un server di integrazione continua attivo in esecuzione, si potrebbe effettivamente spingere la CPU un po 'e l'ultima cosa che si vuole fare è avere qualcosa che impedisce il commit delle modifiche al codice.

Answer 4

Le caselle di sviluppo, per definizione, vengono eliminate e cadute. Viene con il territorio!

Vuoi davvero che questo accada ai tuoi repository di codice sorgente? ...

Answer 5

In aggiunta a ciò che altre persone citate sui server dev essere cestinato regolarmente, v'è un argomento troppo le prestazioni. Se qualcuno sta effettuando qualche sviluppo o test sul server di sviluppo, non si desidera rallentare il server SVN per i checkout o le sincronizzazioni. Inoltre, se si decide di eseguire qualcosa come l'integrazione continua sullo stesso server, non si desidera che tutti i test dell'unità eseguano regolarmente operazioni di sviluppo/test su quel server.

Answer 6

Presso la mia azienda lo abbiamo installato su una macchina dedicata che fornisce spazio di archiviazione ridondante. Immagino che nella nostra cultura attribuiamo un grande valore alla fonte e il tempo e lo sforzo necessari per creare i nostri codici sorgente. Non abbiamo mai installato alcun tipo di macchina di prova che potrebbe essere danneggiata o cancellata perché la configurazione è diventata ingestibile.

woops. teniamo anche il tracciamento dei difetti sulla stessa scatola ma per lo stesso motivo.

Answer 7

Utilizziamo una lavagna vuota e pulita per i nostri repository. Nello specifico, utilizziamo Slicehost per il nostro repository principale.

Abbiamo iniziato con una porzione da 256 MB e successivamente aggiornato a 512 MB. Slicehost è fantastico perché sai che hai un server completamente pulito per iniziare e puoi creare da solo le cose che ti servono.

Slicehosts' articles sono di prim'ordine.

nostro server pronti contro termine si presenta così:

• Ubuntu Hardy Heron
• Subversion
• Apache
• Ruby on Rails
• Warehouse
• Passenger per servire da magazzino tramite Apache
012.
• Backup giornalieri e settimanali tramite Slicehost

E questo è tutto. Non molto sovraccarico.

Modifica: Non tentare di vendere Slicehost qui, quindi se non è kosher, fammi sapere!

Modifica di nuovo: James è un punto eccellente per l'hosting di codice proprietario su un server di terze parti. Prestare particolare attenzione dovrebbe essere preso quando si seleziona un host per fare una cosa del genere. Sfortunatamente, molte aziende semplicemente non hanno le risorse per costruire e gestire server in casa, che è dove ci siamo trovati prima di selezionare un host per il nostro codice.

Answer 8

È sempre meglio mantenere i repository su un server stabile in cui è possibile effettuare backup in modo affidabile quando necessario.