Come posso velocizzare gli aggiornamenti SVN?

Question

Abbiamo un repository SVN piuttosto ampio.Gli aggiornamenti SVN richiedono sempre più tempo quanto più aggiungiamo codice.Abbiamo aggiunto svn:externals alle cartelle che sono state ripetute in alcuni progetti come il FCKeditor su vari siti web.Questo ha aiutato, ma non così tanto.

Qual è il modo migliore per ridurre i tempi di aggiornamento e aumentare la velocità dell'SVN?

Answer 1

Se si tratta di un repository SVN più vecchio (o anche abbastanza nuovo, ma non è stato configurato in modo ottimale), forse utilizza il vecchio stile BDB del database del repository. http://svn.apache.org/repos/asf/subversion/trunk/notes/fsfs ha appunti su quello nuovo.Passare da uno all'altro non è troppo difficile: scarica l'intera cronologia, reinizializzala con il nuovo formato svn del file system e reimporta.Potrebbe anche essere utile allo stesso tempo filtrare il repository-dump per rimuovere interi check-in di informazioni inutili (io, ad esempio, ho rimosso più di 20 MB di file tarball che qualcuno aveva archiviato).

Per quanto riguarda la velocità generale, un disco rigido di qualità (veloce) e memoria extra per la memorizzazione nella cache basata sul sistema operativo sarebbero difficili da criticare in termini di aumento della velocità di funzionamento di SVN.

Sul lato client, se hai configurato tortoisesvn tramite PuttyAgent per l'accesso SSH a un computer con repository esterno, puoi anche abilitare la compressione SSH, che può anche essere d'aiuto.

Modificare: SVN v1.5 ha anche il fsfs-reshard.py strumento che può aiutare a dividere un repository svn basato su FSFS in una serie di directory, che possono essere collegate a diversi mandrini di unità.Se hai migliaia di revisioni, anche questo può essere d'aiuto, se non altro perché trovare un file tra migliaia richiede tempo (e puoi dire se è un problema guardando i tempi di attesa IO)

Answer 2

Disabilita il controllo antivirus sulle cartelle che contengono codice di copia funzionante.Ciò ha fatto sì che i miei aggiornamenti diventassero due volte più veloci.

Answer 3

Non proprio una risposta, ma potrebbe essere interessante sapere che uno dei motivi per cui svn è così pesante in termini di I/O è il fatto che memorizza una copia extra di ciascun file nella directory .svn/text-base.Ciò rende veloci le operazioni di confronto locale, ma consuma molto spazio sul disco rigido e I/O.

http://subversion.tigris.org/issues/show_bug.cgi?id=525 ha i dettagli.

Answer 4

Sembra che tu abbia più progetti in un unico repository.Dividerli dove appropriato ti darà una grande spinta.

Presumibilmente Git è molto più veloce di Subversion a causa del modo in cui memorizza/elabora le modifiche, ma non ho esperienza diretta con esso.

Answer 5

Assicurati che la tua connessione al server sia il più veloce possibile (gigabit ethernet).Assicurarsi che il server disponga di dischi veloci in un array.E, naturalmente, controlla solo ciò di cui hai bisogno.

Answer 6

Ci sono alcune modifiche comuni alle prestazioni.SVN è molto pesante in termini di I/O, quindi i dischi rigidi più veloci sono un'opzione (su entrambe le estremità).Aggiungi più memoria al tuo server.Assicurati che i tuoi client abbiano un disco rigido deframmentato (per Windows).

Anche il metodo di accesso utilizzato è importante.I repository archiviati su file system remoti (utilizzando file:/// access) saranno molto più lenti rispetto a svnserve o Apache con mod_svn.Considera l'utilizzo di uno di questi ultimi se disponi del repository su una semplice condivisione di file.

Answer 7

TotoiseSVN per impostazione predefinita esamina le modifiche ai file in background e ho visto che rallenta la mia macchina.Ho modificato la configurazione per escludere tutto e quindi includere solo le directory in cui ho i checkout.Puoi anche disattivare i controlli dei precedenti.Entrambe queste impostazioni si trovano nel nodo Impostazioni sovrapposizioni icone.

Answer 8

A volte il funzionamento lento di svn, soprattutto con molti esterni, è correlato al DNS.Sembra che svn esegua la ricerca DNS per ogni svn:external, anche per quelli relativi.Può essere utile aggiungere il nome host del server svn a /etc/hosts o correggere resolv.conf.

Answer 9

Ho riscontrato nella mia esperienza (ovvero:non attraverso nessuno effettivo tests) che, soprattutto se il server repo SVN è remoto, l'utilizzo di elementi esterni sembra rallentare le cose.Se hai codice duplicato (come il tuo editor FCK) in più posti, tenderei a limitarmi all'uso di elementi esterni poiché mantenere questi file sincronizzati e gestibili è più importante della velocità di aggiornamento, tuttavia, potresti provare a utilizzare collegamenti simbolici per portare invece in codice duplicato.(Se utilizzi Windows XP, puoi utilizzare punti di giunzione).

Answer 10

Abbiamo suddiviso la nostra base di codice in diversi moduli fratelli e scritto gli script Ant in modo che uno sviluppatore possa lavorare su un modulo alla volta senza preoccuparsi troppo di ciò che accade negli altri moduli.

• uno script di compilazione di livello superiore attiva gli script di compilazione di tutti i moduli
• le librerie esterne lo sono non archiviato in Subversion ma piuttosto estratto da un'unità di rete utilizzando Apache Ivy.(pensalo come un repository Maven interno).
• anche le dipendenze tra i moduli vengono gestite utilizzando Ivy.

In genere, gli sviluppatori dovranno aggiornare l'intero albero un paio di volte a settimana, ma può essere fatto facilmente prima di andare a pranzo o alla pausa caffè.

Answer 11

Utilizzando i diritti di accesso in lettura (ad es.limitare l'accesso in lettura a determinate persone/gruppi) rallenterà molto il repository.Soprattutto quando l'autenticazione viene eseguita in un modo speciale, ad es.contro un dominio Windows.Lo stesso vale ovviamente per i diritti di accesso in scrittura, ma la scrittura è meno frequente della lettura.E limitare l’accesso in scrittura può essere più importante che limitare l’accesso in lettura

Answer 12

Se hai molte cartelle nella radice del repository e la tua copia locale riflette il repository, prova a suddividere la copia locale monolitica in molte cartelle scaricabili separate e ad aggiornare anche queste cartelle separatamente, sarà molto più veloce di una grande cartella.