2012-08-09 7 views
5

Ho un'applicazione Grails sul mio computer locale e ho creato un repository in XP-DEV. Ho le cartelle .groovy e .settings nella radice del progetto. Devo trasferire quei file nel controllo di versione? Sto facendo questa domanda perché non ho idea di quale sia l'uso di queste cartelle.Devo impegnare le cartelle .groovy e .settings nel repository

risposta

10

Aggiornamento

5 anni di esperienza di sviluppo più tardi e penso che ho bisogno di tornare a piedi il mio parere un po 'originale. Continuo a pensare che, in generale, questi file non dovrebbero essere inclusi nel controllo del codice sorgente.

Tuttavia, ci sono alcune impostazioni che è conveniente condividere tra gli sviluppatori. Il problema è che è molto difficile sapere quali impostazioni condividere e quali non condividere. Ad esempio, qualsiasi impostazione con percorsi assoluti in essa non dovrebbe essere condivisa; ma come fai a sapere se la configurazione di un determinato strumento (ad esempio Eclipse, IntelliJ, ecc.) contiene percorsi assoluti?

Se si utilizza git per il controllo della versione, github pubblica molti modelli .gitignore per vari strumenti github/gitignore. Se vuoi provare a condividere le impostazioni, ti consiglio di utilizzare uno di questi modelli.

Se questi modelli non funzionano, rispondo alle mie raccomandazioni originali di non controllare queste impostazioni nel controllo di versione e consentirne la generazione automatica. Quindi, se ci sono impostazioni importanti da condividere (come un modello di codestyle o alcune di queste) fornire istruzioni su come applicare quell'impostazione per tutti gli ambienti di sviluppo previsti.


risposta originale:

.settings è generalmente creato con qualsiasi IDE che si sta utilizzando (lo so Eclipse utilizza questa convenzione) e contiene le impostazioni specifiche del progetto per quanto riguarda l'IDE.

.groovy contiene impostazioni specifiche dell'utente per Groovy. Ad esempio, so che Grape scarica le dipendenze nella directory .groovy.

La mia opinione è, no non impegnare queste directory. Se un'altra persona controlla il tuo progetto, le loro copie personali di queste directory verranno generate automaticamente.

+2

Direi che questo è un _strong_ no. Commettere quelli aggiunge solo confusione e nessun valore. – cdeszaq

+1

Si prega di vedere la mia risposta. Non sono d'accordo. –

9

Non sono d'accordo con la risposta di @FGreg. La cartella .settings contiene impostazioni specifiche del progetto. Ciò include impostazioni del compilatore personalizzate, errori e livelli di avviso, preferenze di formattazione, azioni di salvataggio, ecc. In generale, è una buona idea condividere queste preferenze tra gli sviluppatori. Se queste impostazioni non sono condivise, è possibile che si verifichino incoerenze nella formattazione e nei problemi del compilatore.

In generale, se si desidera un ambiente di sviluppo coerente per qualsiasi team, è necessario includere le cartelle delle impostazioni nel controllo di versione.

La cartella .groovy all'interno di Groovy-Eclipse viene utilizzata per informazioni DSL specifiche del progetto e suggerimenti di inferenza. In generale, se si dispone di informazioni di inferenza specifiche del progetto, è necessario condividerle con altri sullo stesso progetto.

Nel nostro team definiamo chiaramente tutte le impostazioni che verranno utilizzate da ciascun progetto, impegnando le cartelle .settings e siamo certi che ogni sviluppatore vedrà le stesse impostazioni.

2

A mio modesto parere, l'invio del file di progetto IDE è una cattiva idea. Se hai una configurazione specifica, dovresti configurare il tuo esperto, gradle, formica o qualsiasi altra cosa a generare la configurazione corretta.

V'è un elenco di problemi che ho visto

  • Il vostro progetto sarà probabilmente specifica IDE.
  • Si avranno differenze tra sviluppo e integrazione. Rilevererai i problemi più tardi.
  • Il file di configurazione di IDE dipende dalla versione di IDE e dal plug-in installato.
  • Le persone commettono errori (il motivo per cui eseguiamo il controllo del codice sorgente) alcuni file verranno commessi con la configurazione errata.

Se si sceglie di eseguire il commit di questi file, ricordare che sarà necessario eseguire alcuni lavori manuali aggiuntivi per garantire che vengano eseguiti i file corretti. Ma se si configura correttamente lo strumento di compilazione, si eseguirà il lavoro una sola volta. ;)

Problemi correlati