Best practice per un singolo progetto SVN di grandi dimensioni

Question

Ho ereditato un singolo progetto in svn: 30 Gb in oltre 300.000 file. Ci sono un sacco di file binari in gran parte in una cartella di immagini. Operazioni come l'aggiornamento dell'intero progetto possono essere drammaticamente lente.

Il team ha sviluppato un processo per eseguire solo l'aggiornamento/passaggio sulle cartelle specifiche su cui stanno lavorando e ha terminato il controllo del codice interrotto perché "funziona sul mio computer". La copia di lavoro di una persona può includere codice scaduto, codice commutato e codice "mai dimenticato". Inoltre, si verifica una ramificazione minima.

La mia soluzione personale è un piccolo check-out di bash/script di compilazione alle 5 del mattino ogni mattina, tuttavia non tutti hanno il coraggio della linea di comando di copiare anche la mia soluzione e preferiscono il comfort di svn tartaruga e il processo rotto.

Qualcuno ha provato a mettere a punto un repository così grande e può dare consigli? Esistono best practice che posso implementare per lavorare con repository di grandi dimensioni in cui posso semplificare tutti?

P.S. gli esterni non sembrano essere una buona idea e SVN optimizations to keep large repositories responsive non si applica qui perché mi occupo di un singolo progetto

P.P.S. Anche questo viene attualmente esaminato: http://www.ibm.com/developerworks/java/library/j-svnbins.html

Answer 1

Innanzitutto, eseguire l'aggiornamento a SVN 1.6 su client e server. Le note latest release indicano un aumento di velocità per file di grandi dimensioni (r36389).

In secondo luogo, questo potrebbe non essere appropriato per te se devi avere l'intero progetto nella tua copia di lavoro, ma usa sparse directories. Facciamo questo per il nostro grande repo, la prima cosa che un client fa è di controllare solo la directory di primo livello, quindi per ottenere più dati, utilizzare il browser repo per andare alla directory desiderata e "aggiornare a questa revisione" su di esso. Funziona meravigliosamente su TortoiseSVN. 1.6 ha anche l'opzione 'riduci profondità' per rimuovere le directory su cui non hai più bisogno di lavorare.

Se questo non è per voi, è comunque possibile eseguire un aggiornamento su parti della copia di lavoro. L'aggiornamento tende ad essere lento più file si hanno (su Windows, NTFS sembra essere particolarmente povero con la strategia di blocco utilizzata per l'aggiornamento. Bert Huijben noticed this e suggerito una correzione - TBA con la versione 1.7, ma è possibile ricostruire il codice corrente con il suo 'quick fix'

un'alternativa potrebbe essere quella di cambiare il vostro file system, se è possibile riformattare, si potrebbe provare la ext2 IFS driver, ma sono sicuro che si sarebbe prudente che

ultima opzione.! - spegni lo scanner dei virus per le firme .svn e anche per il repository sul server.Se stai eseguendo Apache sul server, assicurati di mantenere viva la tua attività per un breve periodo (per evitare che si verifichi la re-autenticazione). Disattiva inoltre l'indicizzazione sulle directory di copia di lavoro e anche la copia dell'ombra. (l'ultimo non aiuta molto, ma potresti vedere un miglioramento migliore che ho fatto, spegnere l'AV sul server ha aumentato la mia risposta SVN 10x).

Answer 2

Per gestire le dimensioni ingombranti, prenderei in considerazione la possibilità di suddividere i dati binari in un altro ramo (o anche di rimuoverli completamente per essere memorizzati altrove), separati dal codice. Questo dovrebbe almeno velocizzare le cose, specialmente se i dati non cambiano spesso.

Capisco la necessità per le persone di avere una posizione centrale per i loro strumenti, dati e librerie, ma semplicemente non funziona bene con un dump.

Answer 3

Ero un manager SCM in una situazione simile. Abbiamo avuto un progetto con oltre 200K file (principalmente codice) che stava avendo alcuni degli stessi problemi. La nostra soluzione era dividere il repository in due versioni. Una versione è una versione di sviluppo e l'altra è una versione di produzione. Abbiamo seminato la versione di sviluppo con l'ultima e più famosa copia di lavoro di tutto il codice. Gli sviluppatori iniziarono con questo e apportarono modifiche, check-in/out, ecc. Una volta che le cose erano stabili, un amministratore (nel nostro caso un gestore di build) unì il codice e fece test build per verificare che tutto funzionasse correttamente. Se tutto è passato, è stato bello. Se così non fosse, l'amministratore della build darebbe la caccia allo sviluppatore e li punirà severamente. Abbiamo avuto alcuni degli stessi problemi all'inizio dove "Ha funzionato sul mio computer", ecc., Ma in poco tempo sono stati risolti grazie a pestaggi e fustigazioni .....

In alcuni punti il ​​codice di sviluppo (TUTTO IL CODICE DI LAVORO !!!!) è stato ricollegato alla produzione e rilasciato al cliente.

Answer 4

Abbiamo due repository, uno per il nostro codice (cambia frequentemente) e un altro per i nostri dati binari (molto grande, cambia di rado). A volte è un dolore, ma vale la velocità migliore quando si lavora con il codice.

Abbiamo anche uno script Ruby che chiamiamo "aggiornamento giornaliero", controllato nel nostro repository, che iniziamo ogni giorno con tutti i PC di sviluppo tramite una Pianificazione di Windows. Aggiorna entrambi i checkout alla versione più recente, quindi crea tutto localmente, quindi siamo pronti a partire non appena arriviamo al mattino.

Ci sono alcuni inconvenienti che non abbiamo ancora risolto - ad esempio, quando i nostri test automatici sono eseguiti, c'è attualmente un ritardo tra quando controllano il codice e quando controllano i dati, così quando eseguiamo il commit le modifiche a entrambi i repository, il server CI a volte ottiene il vecchio codice e nuovi dati, che provoca errori di test.

Quando commettiamo modifiche all'archivio dati, di solito comunichiamo a tutti gli altri che devono aggiornare (ci siedo tutti nella stessa stanza). Altrimenti, di solito non aggiorniamo i dati manualmente; lasciamo che lo script di aggiornamento giornaliero lo mantenga fresco.

Answer 5

È possibile suddividere il progetto in progetti più piccoli che possono essere collegati tramite una sorta di sistema di plugin?

Answer 6

Lo terrò breve:

• aggiornamento alla versione più recente (1.6.x). 1.5.x aveva anche ottimizzazioni della velocità.
• Assicurarsi che tutti utilizzino la stessa versione di TortoiseSVN che è stata costruita sulla versione esatta del server. Abbiamo avuto molti problemi con ragazzi che si aggiornavano per capriccio e poi avevano problemi strani.
• Gli esterni funzionano tra server, repository e cartelle sullo stesso repository. Quindi tu puoi spostare i binari su un altro repository/server e collegarli semplicemente a quelli esterni.
• Riorganizzare le cartelle in modo da poter eseguire il controllo spoglio del progetto ed essere ancora in grado di lavorare in modo produttivo. Fondamentalmente tutti controllano la cartella top + children solo poi in modo selettivo "aggiorna in revisione" le cartelle che devono controllare completamente.
• Creare script che esportano, costruiscono quindi eseguono il commit (o richiedono di eseguire il commit). Ho questi script per il mio uso. Prima di eseguire il commit, eseguo lo script ed esporta il mio wc e quindi lo costruisce. NOTA: questo copierà il wc completo!Quindi questo è utile con checkout sparsi dove la dimensione dei dati è piccola (er).
• Considerare di spostare i file binari dal repository (non lo consiglio, ma potrebbe essere la soluzione più sicura per aumentare la produttività).
• Ricordare che l'esportazione non crea un wc, il che significa che si risparmia il 50% di spazio su disco rispetto ai checkout. Quindi, se si ristrutturano in modo tale che i file binari e gli articoli meno frequentemente aggiornati possano essere esportati al posto del pagamento, incoraggerebbero più persone a "ottenere il risultato completo" e non tentare di scremare un po 'di esso.