Quali file Eclipse è appropriato mettere sotto il controllo del codice sorgente, a parte i sorgenti ovviamente?
Nel mio progetto, in particolare, mi chiedo:
.metadata / *
project-dir / .project
project-dir / .classpath
project-dir / .settings / *
Se ce ne sono alcuni per i quali dipende, spiega le linee guida.
Risposte:
I metadati non devono essere gestiti nel controllo del codice sorgente. Contengono principalmente dati rilevanti per il tuo spazio di lavoro.
L'unica eccezione sono i .launchfile XML (definizione di avvio).
Si trovano in
[eclipse-workspace]\.metadata\.plugins\org.eclipse.debug.core\.launches
E dovrebbero essere copiati nella directory del progetto: quando il progetto viene aggiornato, tali configurazioni verranno visualizzate nella finestra di dialogo "Esegui configurazione".
In questo modo, i file dei parametri di avvio possono anche essere gestiti in SCM.
(Attenzione: deselezionare l'opzione "configurazioni Elimina quando risorsa associata viene eliminato" nella Run / Avvio / Launch Configuration pannello delle preferenze: E 'comune a soft-cancellare un progetto per importare di nuovo - per forzare una reinizializzazione del metadati di eclissi. Ma questa opzione, se selezionata, rimuoverà i parametri di avvio dettagliati!)
project-dir/.project
project-dir/.classpath
project-dir/.settings/*
dovrebbe essere nel tuo SCM (in particolare .projecte .classpathsecondo la documentazione Eclipse ).
L'obiettivo è che chiunque possa effettuare il checkout / aggiornare la propria area di lavoro SCM e importare il progetto Eclipse nell'area di lavoro Eclipse.
Per questo, vuoi usare solo percorsi relativi nel tuo .classpath, usando risorse collegate .
Nota: è meglio se si project-dirriferisce a una directory di progetto "esterna", non a una directory creata nell'area di lavoro di eclipse. In questo modo, le due nozioni (area di lavoro eclissi e area di lavoro SCM) sono chiaramente separate.
Come menziona ipsquiggle nel commento e come ho accennato in una vecchia risposta , puoi effettivamente salvare la configurazione di avvio come file condiviso direttamente nella directory del progetto. Tutta la configurazione di avvio può quindi essere versionata come gli altri file di progetto.
(Dal post sul blog Suggerimento: creazione e condivisione di configurazioni di avvio da KD)
.projectignorata per il momento solo per il tuo spazio di lavoro. Ma non privare tutti gli altri utenti della comune definizione del progetto Eclipse che possono importare rapidamente nel loro spazio di lavoro Eclipse, solo perché ti capita di avere una definizione extra che si adatta solo alle tue necessità del momento.
Attualmente sto lavorando a un progetto in cui abbiamo i file .project e .cproject sotto il controllo del codice sorgente. L'idea era che le impostazioni relative ai percorsi delle librerie e alle direttive sui collegamenti si propagassero attraverso il team.
In pratica non ha funzionato molto bene, le fusioni ritornano quasi sempre in uno stato di conflitto che deve essere deconflitto al di fuori dell'eclissi e quindi il progetto viene chiuso e riaperto affinché le modifiche abbiano effetto.
Non consiglierei di tenerli nel controllo del codice sorgente.
Non vale nulla che i file di configurazione di CDT non siano compatibili con il controllo del codice sorgente. C'è un bug archiviato per i file .cproject che cambiano molto frequentemente e causano conflitti, vedere La condivisione dei file di progetto cdt nel repository causa sempre conflitti .
Alcuni progetti, come quelli che utilizzano Maven, amano generare i file .project basati su POM.
Detto questo, a parte questo - .metadata NON dovrebbe essere nel controllo del codice sorgente. Il tuo progetto dovrà decidere se projectdir / .settings lo fa, in base a come prevedi di gestire gli standard e simili. Se puoi fidarti onestamente dei tuoi sviluppatori di impostare il loro ambiente in base allo standard e non devi personalizzare nulla di speciale per qualsiasi progetto, non è necessario inserirli. Io, ti consiglio di configurare ogni progetto in modo specifico . Ciò consente agli sviluppatori di lavorare su più progetti nello stesso spazio di lavoro senza dover cambiare le impostazioni predefinite avanti e indietro e rende le impostazioni molto esplicite, ignorando qualsiasi impostazione predefinita corrisponda agli standard del progetto.
L'unica parte difficile è assicurarsi che rimangano tutti sincronizzati. Ma nella maggior parte dei casi è possibile copiare i file .settings da un progetto all'altro. Se ce ne sono alcuni che non vuoi specificamente nel controllo del codice sorgente, fai l'equivalente dell'impostazione svn: ignora per loro, se SCM lo supporta.
Il file .classpath è sicuramente un buon candidato per il controllo di scm in quanto impostarlo a mano può richiedere molto lavoro e sarà difficile per i nuovi sviluppatori entrare nel progetto. È vero che può essere generato da altre fonti, nel qual caso verrai verificato nell'altra fonte.
Per quanto riguarda .settings, dipende dalle impostazioni. Questa è un'area grigia, ma alcune impostazioni sono quasi obbligatorie ed è conveniente essere in grado di controllare un progetto, importarlo in Eclipse e avere tutto pronto e pronto.
Nel nostro progetto, pertanto, conserviamo una copia della cartella .settings chiamata CVS.settings e abbiamo un compito formica per copiarla in .settings. Quando si ottiene il progetto da CVS, si chiama l'attività ant 'eclipsify' per copiare le impostazioni predefinite nella nuova cartella .settings. Quando si configurano le impostazioni necessarie a tutti gli sviluppatori del progetto, le si uniscono nuovamente nella cartella CVS.settings e le si impegna in CVS. In questo modo il salvataggio delle impostazioni in SCM diventa un processo consapevole. Richiede agli sviluppatori di ricollegare tali impostazioni nelle loro cartelle .settings di volta in volta quando si effettuano grandi cambiamenti. Ma è un sistema semplice che funziona sorprendentemente bene.
Direi nessuno di loro. Molto probabilmente contengono informazioni rilevanti solo per la tua workstation (sto pensando ai percorsi per le librerie e tutto il resto). Inoltre, se qualcuno nel tuo team non utilizza Eclipse?
Tener conto di:
.classpath
.project
.launch
DOVREBBE essere nel controllo della versione purché si utilizzi percorsi relativi al progetto. Ciò consente ad altri sviluppatori di verificare il progetto e iniziare a lavorare immediatamente senza dover affrontare tutto il dolore di installazione che hanno subito anche altri sviluppatori.
Potresti essere tentato di includere .metadata anche nel controllo della versione in modo che gli sviluppatori di Eclipse possano controllare un intero spazio di lavoro e averlo preconfigurato con tutti i progetti giusti, ma include molte informazioni specifiche dell'utente che ogni volta che qualcuno ci lavora, lo farà cambiare, quindi consiglierei di NON INCLUDERE .metadata. È facile costruire uno spazio di lavoro locale semplicemente importando tutti i progetti Eclipse esistenti.
Ho trascorso troppe ore a configurare le impostazioni dell'area di lavoro di eclipse per i nuovi colleghi (e me stesso). Quello che alla fine ho fatto è stato copiare i miei .metadata sulla nuova macchina sviluppatore.
Se stai lavorando in una squadra, penso che i seguenti siano candidati molto validi da tenere sotto controllo della versione:
commonscheda, scegliSave as > shared file. Questo lo rilascia direttamente nella cartella del progetto, quindi può essere SCM con il resto del progetto.