2012-04-21 12 views
6

Sto utilizzando EGit su un insieme di progetti Java abbastanza grande e complesso (più di un milione di righe di codice) e un decennio di storia.
Qui sto affrontando seri problemi di prestazioni con EGit, poiché anche una piccola modifica di una riga nel file Java fa sì che EGit ri-indicizzi per un paio di minuti, il che sta rallentando l'intero sistema. Infatti, anche la riga di comando git è un po 'lenta poiché "git status" impiega circa un minuto dalla riga di comando, ma posso vivere con questo problema di prestazioni, & Problema di lentezza della finestra di dialogo commit commit (link). Come posso usare git command line per commettere e aggiornare, ma non voglio compromettere le mie prestazioni di Eclipse in quanto ciò influisce sulla produttività.Suggerimenti sull'ottimizzazione dell'Egit su Eclipse

Quello che segue è quello che ho cercato facendo usare Google e chiedere alla gente in giro:

  1. Aggiunto cartella tutte le classi nel file escludere. Effettivamente provato a mettere la cartella delle classi in .gitignore pure per tempo.
  2. Dato necessario Tempo sufficiente per terminare l'indicizzazione mantenendo la macchina accesa per un giorno.
  3. Lo staging Git, la cronologia e tutte le altre viste Eclipse vengono chiuse nel workbench di Eclipse durante lo sviluppo.
  4. Ha fatto "git gc" - Ha fatto la differenza sulle prestazioni della riga di comando, ma praticamente nessuna differenza per EGit.
  5. Decoratore di etichette non selezionato per Git. Preferenze -> Generale -> Aspetto -> Decorazioni etichetta.
  6. Rimosso il cygwin dal percorso, come letto da qualche parte nel forum che JGit potrebbe utilizzare cygwin per la conversione del percorso.
  7. Aumentata la cache della finestra da 10 a 70 m in Eclipse (Preferenze -> Team -> Git -> finestra cache).

PS: repository Git punta al repository svn remoto. Inoltre, sono git newbie quindi potrebbe aver fatto qualche errore nel setup, quindi per favore sentitevi liberi di indicare qualsiasi cosa.

Ecco le informazioni sul mio sistema, non ho molte specifiche hardware di fantasia, ma un po 'di RAM da risparmiare (8 GB).

  • versione git-gui 0,16 GITGUID
  • versione git: 1.7.10.mysysgit.1
  • JDK 1.6_025
  • Eclipse versione: La versione 3.7.2 Java EE con i parametri -Xms1536m -Xmx1536m
  • EGit: 1.3.0.201202151440
  • Windows 7 processore: core 2 Duo 2,6 GHz

risposta

0

Questo è il problema tra CVCS (VCS centralizzato) e DVCS (distribuito) VCS:

  • Un repository SVN può contenere GB di dati.
  • un repository Git dovrebbe essere mantenuto piccolo, e sfruttare il submodules per rappresentare, attraverso più repository Git.

Sospetto che molti repository potrebbero funzionare meglio di un gigantesco repository Git. In caso contrario, inizieranno a verificarsi problemi di sincronizzazione, come in bug 323839.

Ma questo significa gestire la sincronizzazione (semplificata) tra repository Git e il repository SVN manualmente, attraverso uno spazio di lavoro SVN da cui si copia da repository yourGit o verso cui si sta copiando Git reinserire nuove evoluzioni nel Spazio di lavoro SVN per eseguire il commit.

+1

VonC - Accetto, ma c'è sicuramente qualche problema con l'implementazione di Egit, visto che lo stesso grande repo git si comporta abbastanza bene su Linux con IntelliJ), anche se sono d'accordo che i file system di Linux sono molto più veloci. Quindi, posso creare un repo Git centrale che è clone di SVN e quindi avere più repo Git multipli dal repo centrale Git gigante? – Hemant

+0

@Hemant no, non è possibile (non con la possibilità di riprendere il repository SVN). È possibile definire un repo Git che dichiara tutti i piccoli come sottomoduli, ma non ci sarà alcun collegamento con un repository SVN. Ciò lascia un meccanismo di sincronizzazione manuale. – VonC

+0

Vonc - Grazie per averlo chiarito. Continuerò ad esplorare le mie opzioni ... inoltre spero che il team di Egit esegua un po 'di ottimizzazione delle prestazioni più velocemente. – Hemant

3

Questo probabilmente non è proprio un problema, ma questa pagina si trova su google per quanto riguarda le prestazioni di egit. Una volta l'origine dei problemi di prestazioni è file non indicizzati (indicizzati?). Assicurati di non avere un numero elevato di file non tracciati nell'albero delle directory locali poiché questo ha un impatto negativo sulle prestazioni. Ho rimosso un director con file 10K + e il commit delle prestazioni è passato da 1+ minuto per aprire la finestra di dialogo di commit in un paio di secondi.

+0

Non ho file non tracciati nel mio repository. Sto lavorando sull'enorme repository che contiene circa 28k di file Java e 136k di commit, ma la maggior parte dovrebbe essere già pronta. – Hemant

+0

Prova a clonare 'git: // git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git'. Un checkout del kernel Linux ha circa 45k file e il kernel ha ben oltre 300k commit. Un repo con file 28k e commit di 136k è un grande, non enorme. –

+0

Per un enorme repo, prova a clonare 'https: // github.com/mozilla/gecko-dev.git'. Il clone dovrà trasferire circa 1,5 GB di dati su un solo filo ... –

Problemi correlati