Nella mia esperienza, escludendo i casi limitati in cui sono coinvolte impostazioni puramente locali, tutto dovrebbe essere nel controllo del codice sorgente. La legge del controllo del codice sorgente è che tutto ciò che viene inserito dovrebbe funzionare da coloro che si ritirano. Sfortunatamente, eclipse spesso fa sì che cose come questa siano in .classpath:
<classpathentry kind="con"
path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.launching.macosx.MacOSXType/Java SE 7"/>
Quindi sul mio Mac funziona, e forse qualcuno su un Mac ha lo stesso JRE, ma questo non funzionerà per nessun altro.
Inoltre, non c'è un modo semplice per aggirare questo problema. Eclipse lo aggiungerà sempre. VOGLIO avere il file .classpath lì, perché ci sono alcuni JAR di terze parti nella nostra cartella lib in cui ci interessa il controllo delle versioni, quindi li lasciamo lì in modo che i nuovi sviluppatori non debbano averli . Stiamo passando a un sistema gestito, ma abbiamo ancora controllato + dipendenze non gestite. Ciò significa che tutti gli sviluppatori devono solo assicurarsi che due directory siano nelle loro .classpaths. Ma è meglio che dover aggiustare il tuo JRE ogni singola volta che tiri e fai un cambiamento nel tuo .classpath ogni singola volta che effettui il commit.
Eclipse fa altre cose carine per te però. Il file .project sarà solitamente lo stesso in tutte le istanze, quindi includilo. Ma la cosa migliore del controllo del codice sorgente per eclipse sono le impostazioni di Esegui configurazioni. Nella scheda "Comune" nella finestra di dialogo Esegui configurazioni, salva le configurazioni in modo che appaiano ai tuoi colleghi negli elenchi dei preferiti per Debug ed Esegui. Per me, un sacco di .launchfile vanno nella .settingsdirectory, quindi possiamo usarli tutti.
Quindi dico: la .settingsdirectory entra nel controllo del codice sorgente per le configurazioni di avvio (tranne * .prefs)
.classpath resta fuori
.project entra.
