Controllo in un progetto Eclipse in SVN

Question

voglio checkin un progetto Web dinamico che ho creato in Eclipse in svn. Qualcuno può dirmi quali file devo controllare e quale non dovrei? L'idea è di essere in grado di controllare il progetto utilizzando la procedura guidata Nuovo progetto in modo da poter creare nuovamente il Dynamic Web Project. In particolare ecco i file/directory che ho in progetto -

• src
• WebContent
• accumulo
• dist
• build.xml
• .project
• .classpath
• .settings/

la cartella di generazione non dovrebbe check-in, ovviamente. E gli altri? Sto indovinando tutto il. i file non dovrebbero essere controllati in nessuno dei due. Qualcuno può verificarlo? Cos'è questa directory dist e la directory .settings?

anche dove non eclissi memorizzare le informazioni di Server (Tomcat)? Non voglio controllarlo in nessuno dei due.

EDIT:

inizialmente ho registrato tutto quanto sopra, tranne la cartella di generazione, naturalmente. Quando ho controllato il progetto dall'interno di Eclipse, non mi ha richiesto di creare un nuovo progetto dal momento che .project è presente ma Eclipse stava creando un progetto JavaEE o qualcosa del genere invece del progetto Web dinamico. Qualcun altro ha incontrato questo comportamento?

** MODIFICA 2 **

Trovato! Si scopre che non dovrei check-in seguente -

• .project
• .settings/
• .classpath

Una volta che questi 3 sono rimossi il New Project Wizard funziona come previsto e tutto è ok.

Answer 1

Se si effettua il check-in .classpath/.project/.settings, si rende specifico il progetto Eclipse. Che dire degli sviluppatori che lavorano con Netbeans o IntelliJ? IMO è più pulito per mantenere il tuo progetto IDE indipendente e facile da configurare.

Di solito vado per una build Maven. Lo pom.xml specifica tutte le dipendenze richieste e mvn eclipse:eclipse genera i file .classpath/.project.

La directory .settings contiene impostazioni locali (come la versione di Java che si desidera utilizzare). IMO non è utile controllarlo. È possibile applicare la conformità della versione Java tramite Maven2 pom.

Infine, per il tuo prossimo progetto, il mio protip è svn-ignore i file o le directory che non vuoi in SVN prima del il tuo primo commit. In una configurazione Maven2 che sarebbe .settings.classpath.projecttarget (la directory di output predefinita di Maven2) e qualsiasi altra roba generata (file di registro, directory gfembed, ecc.). Nel tuo caso ignoreresti build e dist invece di target.

È possibile i file o le directory svn-ignore con RIGHT_MOUSE->Team->'Add to svn:ignore' (utilizzo il plug-in Subclipse). Le istruzioni ignorate vengono memorizzate come svn-properties nella directory superiore. Le proprietà su una directory possono essere visualizzate da RIGHT_MOUSE->Team->Show properties. È anche possibile modificare le proprietà direttamente lì facendo clic sul campo del valore. Assicurati che ci sia una fine di linea dopo ogni proprietà.

Ora che hai già eseguito il commit e quindi rimosso questi file, ignorando non funzionerà più nella mia esperienza. In qualche modo non sono mai riuscito a ignorare con successo i file generati che sono stati mai controllati nel repository SVN; sono come gli zombi, tornano sempre dalla morte. Forse eliminando fisicamente le loro voci nel repository SVN questo può essere ottenuto, ma non l'ho mai fatto.

Answer 2

Vorrei omettere il .project, .settings /, dist e build.

Il percorso .class può essere lasciato in se si utilizzano variabili anziché percorsi codificati. Questo è utile in modo da non dover ricostruire il classpath ogni volta che si controlla il progetto.

Answer 3

Nel nostro caso, abbiamo controllato tutto ciò che hai menzionato nell'elenco, ad eccezione di .settings /.

Con .classpath e .project il check-in, gli utenti possono controllare rapidamente il progetto e al fuoco fino Eclipse su un nuovo computer e iniziare a lavorare su di esso; l'alternativa è quella di configurare il progetto manualmente e aggiungere tutte le dipendenze del vaso in modo accurato (se si usa formica). Molti progetti open source fanno questo.

Leggi this, ci sono alcuni veramente buoni punti su cui riflettere circa.

Answer 4

Buona domanda ... Molti di noi sono in un dilemma se vogliamo archiviare i file relativi all'IDE o no. Normalmente vado per il check in .classpath per eclipse e uso le variabili di eclipse per assicurarmi che il team debba solo cambiare il valore della variabile e funzioni. Effettuiamo anche il check-in .project in modo che il team non debba creare nuovi progetti nel proprio spazio di lavoro.