Quali file devono essere aggiunti a SVN in un progetto Java di eclissi?

Question

Ho un progetto Java che vorrei trasferire sul mio repository SVN, creato con eclipse.

Ora, quali file (oltre al codice sorgente, ovviamente) sono necessari? Nella root dell'area di lavoro, c'è una cartella .settings con molti file e sottocartelle e all'interno della cartella del progetto ci sono due file: .classpath e .project e un'altra cartella .settings con un singolo file - org.eclipse.jdt.core .prefs.

Quali di questi file devono essere impegnati in SVN e quali possono essere esclusi in modo sicuro?

Answer 1

Sono tutti utili se si desidera disporre di impostazioni coerenti all'interno del proprio team.

.classpath e .project significa che tutti possono essere operativi con un progetto solo importandolo. Eventuali modifiche alle librerie e ai file di origine inclusi nel progetto verranno rilevate da tutti al momento del check-in.

La directory .settings ha cose come le opzioni di formattazione del codice e ciò che il compilatore considera come avvertenze, errori o OK . Per coerenza, ho iniziato a controllarli (purché tutti i membri del team siano d'accordo con uno standard per la formattazione, immagino).

Ho scoperto che il limite più grande nella condivisione di cose tra il controllo di versione in Eclipse è nelle definizioni di libreria. Le definizioni di libreria sembrano essere memorizzate solo per utente, quindi se si fa riferimento a una "libreria" nel file .classpath, ogni altro utente deve definire manualmente il contenuto di tale libreria (o importare manualmente il file delle definizioni delle librerie esportate) .

---

Edit:(commento Rivolgendosi @ di mliebelt sotto)

Faresti solo impegnarsi file .settings se si sta cercando di mantenere la consistenza/standardizzazione tra gli sviluppatori. Se questo non è un problema per il progetto, quindi non commettere i file .settings è una cosa in meno di cui preoccuparsi per il mantenimento. I file specifici dei plug-in preferiti di un individuo probabilmente non hanno bisogno di essere commessi (anche se non credo che sarebbe dannoso se lo fossero, verrebbero probabilmente ignorati?).

I due più comuni che ho trovato degno di essere commessi sono org.eclipse.jdt.core.prefs e org.eclipse.jdt.ui.prefs, che sono fondamentali per qualsiasi progetto (Java) Eclipse.

Answer 2

È possibile escludere la cartella .settings, ma il file .project sarà utile per altri sviluppatori che desiderano ricostruire lo stesso esatto progetto Eclipse. Se si esamina il file, dovrebbe avere solo riferimenti relativi (in caso contrario, è necessario modificarlo come tale).

Answer 3

In contrasto con le altre risposte ho fatto esperienze migliori con non verificando il file .project in grandi progetti open source con cui lavoro.

Potrebbe non essere d'accordo con me, ma c'è un problema con i file .project condivisi: contengono riferimenti alle nature del progetto utilizzate nel progetto. Le nature del progetto dipendono ancora dai plug-in installati sulla macchina degli sviluppatori locali.

Esempio: se si utilizza Findbug su un progetto Java, viene aggiunta una nuova natura al progetto Java.Controllando che il file in, modificandolo su un altro sistema (senza Findbugs installato) e dopo averlo usato di nuovo sul mio sistema, ha portato a perdere il riferimento a Findbugs per me (e quindi tutti i controlli di Findbug vengono rimossi in silenzio).

Tuttavia, se tutti i tuoi sviluppatori sono d'accordo sull'utilizzo degli stessi strumenti, è possibile risolvere facilmente questo problema.