Modifica: a differenza di alcune domande simili come Spostamento di un repository SVN multi-GB su Git o link Il mio scenario non coinvolge diversi sottoprogetti che possono essere facilmente convertiti in submoduit git, né alcuni file binari molto grandi che sono adatti per git-annex. È un singolo repository in cui i binari sono la suite di test strettamente accoppiata al codice sorgente principale della stessa revisione, proprio come se fossero risorse di tempo compilabili come la grafica.
Sto studiando il passaggio da un vecchio repository di codice di dimensioni medio / grandi (50 utenti, revisioni 60k, cronologia 80Gb, copia di lavoro 2Gb) da svn. Man mano che il numero di utenti è cresciuto, c'è molto churn in trunk e le funzionalità sono spesso distribuite su più commit rendendo difficile la revisione del codice. Inoltre, senza diramazione non c'è modo di "uscire" dal codice errato, le recensioni possono essere fatte solo dopo che è stato impegnato nel trunk. Sto studiando alternative. Speravo che potessimo passare al git, ma ho qualche problema.
Il problema con il repository corrente per quanto riguarda git è la dimensione. C'è un sacco di vecchi cruft, e pulirlo con --filter-branch quando si converte in git può ridurlo in dimensioni di un ordine di grandezza, a circa 5-10 GB. Questo è ancora troppo grande. La più grande ragione per la dimensione del repository di grandi dimensioni è che ci sono molti documenti binari che sono input per i test. Questi file variano tra .5mb e 30mb e ce ne sono centinaia. Hanno anche molti cambiamenti. Ho esaminato i sottomoduli, git-annex, ecc, ma avere i test in un sottomodulo è sbagliato, così come avere un allegato per molti file per i quali si desidera avere una cronologia completa.
Quindi la natura distribuita di git è davvero ciò che mi impedisce di adottarlo. Non mi interessa davvero distribuito, voglio solo la ramificazione economica e potenti funzionalità di fusione. Come suppongo che faccia il 99,9% degli utenti git, useremo un repository centrale benedetto e nudo.
Non sono sicuro di capire perché ogni utente deve avere una cronologia locale completa quando si utilizza git? Se il flusso di lavoro non è decentralizzato, che cosa stanno facendo quei dati sui dischi degli utenti? So che nelle versioni recenti di git puoi usare un clone poco profondo con solo una storia recente. La mia domanda è: è praticabile farlo come modalità operativa standard per un intero team? Può essere configurato per essere sempre superficiale in modo da avere una cronologia completa solo centralmente, ma gli utenti di default hanno solo 1000 giri di storia? L'opzione ovviamente sarebbe quella di convertire solo 1000 giri in git e mantenere il repository svn per l'archeologia. In tale scenario, tuttavia, riscontreremmo di nuovo lo stesso problema dopo le prossime migliaia di revisioni dei documenti di test.
- Quale è una buona pratica migliore per l'utilizzo di git con repository di grandi dimensioni contenenti molti file binari per i quali fai vuoi la cronologia? La maggior parte delle best practice e dei tutorial sembrano evitare questo caso. Risolvono il problema di alcuni binari enormi o propongono di eliminare completamente i binari.
- La clonazione superficiale è utilizzabile come una normale modalità operativa o è un "trucco"?
- I sottomoduli possono essere utilizzati per il codice in cui si ha una stretta dipendenza tra la revisione del sorgente principale e la revisione del sottomodulo (come nelle dipendenze binarie del tempo di compilazione o in una suite di test unitario)?
- Quanto è grande "troppo grande" per un repository git (in locale)? Dovremmo evitare di cambiare se riusciamo a portarlo a 4 GB? 2GB?