2010-07-16 12 views
6
  1. Ogni membro del team crea il proprio spazio di lavoro e importa il progetto archiviato sotto il controllo del codice sorgente? O c'è un modo per mettere lo spazio di lavoro anche sotto il controllo del codice sorgente?
  2. Come evitare l'utilizzo di percorsi assoluti nella configurazione dello spazio di lavoro?
  3. Ci sono altri colli di bottiglia in questa attività?

risposta

2

Una persona di percorso deve generare i progetti Eclipse dal file di generazione. Ciò ha un ulteriore vantaggio se l'ambiente di sviluppo è progettato per non avere una struttura rigida (ad esempio il percorso della libreria X può essere relativamente diverso nell'ambiente Y rispetto all'ambiente Z) poiché gli stessi dati di configurazione (file, variabili d'ambiente, ecc.) Possono essere utilizzato per impostare il progetto Eclipse come ambiente non Eclipse.

3

Non inserire Workspace in SCM; ciò richiederebbe che l'ambiente di ciascun sviluppatore fosse identico. Invece fai attenzione a evitare percorsi hard-coded; usa le variabili dello spazio di lavoro.

Utilizzare Project Set Files per identificare e condividere gruppi di progetti che devono essere importati in un'area di lavoro. Questi file possono/devono essere mantenuti in SCM, forse in progetti di rilascio dedicati.

La mia pratica quando si lavora seriamente su un'applicazione è iniziare con uno spazio di lavoro pulito, senza progetti estranei. Popolare usando il PSF.

+0

Come ho capito, la funzione "Project Set Files" funziona solo con CSV, questo non è appropriato per me. –

Problemi correlati