Prestazioni di sovrapposizione di file TortoiseSVN: esiste un modo per migliorarlo?

Question

Sto usando TortoiseSVN sul mio computer di sviluppo (con Windows Server 2003) e VisualSVN Server sul lato server. Entrambe sono le ultime versioni (contro Subversion 1.6.5).

Tutto funziona bene in generale; tuttavia mi sento un po 'frustrato con gli overlay di file TortoiseSVN (le piccole icone che mostrano stati bloccati o modificati sui file in Explorer). A volte queste sovrapposizioni sembrano aggiornarsi istantaneamente dopo un commit o un lock, a volte cambiano solo dopo un paio di aggiornamenti, ea volte mostrano completamente lo stato sbagliato fino al prossimo riavvio.

Potrebbe essere una domanda impossibile rispondere, data la quantità di variabili (altro software installato, ad esempio), ma ci sono trucchi noti per accelerare l'aggiornamento di questi overlay?

Answer 1

Di gran lunga l'aumento più grande spettacolo ho avuto è stato quello di impostare del cliente Icon Overlay di non processare l'intero disco rigido, solo le posizioni miei file SVN vivono.

A tale scopo, aprire le impostazioni (destra fare clic in Explorer-> TortoiseSVN-> Impostazioni), selezionare Icon overlay, poi nel Escludi percorsi: immettere c:\*

nel percorsi di inclusione: Inserisci i percorsi tuoi Subversion directory copia di lavoro (per me tutti sono sotto.210 e c:\workspaces\*)

Utilizzare un ritorno a capo per separare le voci (vedi screenshot)

Ciò ha reso il cliente sembra un migliaio di volte più veloce.

Questa schermata mostra come escludere C: e D: unità, appena comprese le directory rilevanti:

è possibile ottenere alcuni ulteriori suggerimenti di prestazioni dalla TortoiseSVN docs.

Answer 2

disable TSVNCache.exe altogether. Ho deciso che ero disposto a vivere senza icone aggiornate se ciò significava che potevo aprire e chiudere ordini di grandezza di Visual Studio più velocemente.

Si potrebbe anche ridurre la priorità di TSVNCache, che è ciò che il mio capo ha fatto con successo. Il problema principale che stavamo avendo erano i tempi di avvio e di spegnimento di Visual Studio, quindi ha scritto un file batch che ha abbassato la priorità del processo e ha quindi avviato VS.