Quels fichiers Eclipse appartiennent au contrôle de version ?

Question

Quels sont les fichiers Eclipse qu'il convient de mettre sous contrôle de source, à part les sources évidemment ?

Dans mon projet, plus précisément, je m'interroge sur :

.metadata/*
répertoire-projet/.projet
répertoire du projet/.classpath
répertoire du projet/.paramètres/*

Si cela dépend de l'un d'entre eux, veuillez expliquer vos directives.

Answer 1

Les métadonnées ne doivent pas être gérées dans le contrôle des sources. Elles contiennent principalement des données relatives à votre espace de travail.

La seule exception est le .launch Fichiers XML (définition du lanceur).

On les trouve dans

[eclipse-workspace]\.metadata\.plugins\org.eclipse.debug.core\.launches

Et ils doivent être copiés dans le répertoire de votre projet : Lorsque votre projet sera actualisé, ces configurations seront affichées dans la boîte de dialogue "Run configuration".

De cette façon, ces fichiers de paramètres de lancement peuvent également être gérés dans le SCM.

(Avertissement : Ne pas décochez l'option "Supprimer les configurations lorsque la ressource associée est supprimée". en el Exécuter / Lancement de / Configuration du lancement le panel des préférences : Il est courant de supprimer progressivement un projet afin de le réimporter - pour forcer une réinitialisation des métadonnées d'eclipse. Mais cette option, si elle est cochée, supprimera vos paramètres de lancement détaillés).

project-dir/.project
project-dir/.classpath
project-dir/.settings/* 

devrait être dans votre SCM (en particulier .project y .classpath selon le Documentation Eclipse ).

L'objectif est que chacun puisse vérifier/mettre à jour son espace de travail SCM et importer le projet Eclipse dans l'espace de travail Eclipse.

Pour cela, vous devez utiliser uniquement chemins relatifs dans votre .classpath, en utilisant ressources liées .

Remarque : il est préférable que project-dir fait référence à un répertoire de projet "externe", et non à un répertoire créé sous l'espace de travail d'eclipse. De cette façon, les deux notions (espace de travail eclipse vs. espace de travail SCM) sont clairement séparées.

---

Comme ipsquiggle mentionne dans le commentaire, et comme j'y ai fait allusion dans une ancienne réponse vous pouvez en fait sauvegarder la configuration de lancement en tant que fichier partagé directement dans le répertoire de votre projet. Toute la configuration de lancement peut alors être versionnée comme les autres fichiers du projet.

(Extrait de l'article du blog Conseil : Création et partage des configurations de lancement de KD)

Answer 2

Je travaille actuellement sur un projet dont les fichiers .project et .cproject sont sous contrôle de source. L'idée était que les paramètres liés aux chemins des bibliothèques et aux directives de liaison se propagent dans toute l'équipe.

En pratique, cela n'a pas très bien fonctionné, les fusions reviennent presque toujours dans un état conflictuel qui doit être déconflictuel en dehors d'eclipse, puis le projet est fermé et rouvert pour que les changements prennent effet.

Je ne recommanderais pas de les garder dans le contrôle de source.

Answer 3

Cela ne vaut rien que CDT Les fichiers de configuration ne sont pas adaptés au contrôle de la source. Il y a un bogue enregistré pour les fichiers .cproject qui changent très fréquemment et causent des conflits, voir _Le partage des fichiers cdt-project dans le référentiel provoque toujours des conflits_ .

Answer 4

Certains projets, comme ceux qui utilisent Maven, préfèrent générer les fichiers .project à partir des POM.

Cela dit, à part cela - .metadata ne devrait PAS être dans le contrôle de source. Votre projet devra déterminer si projectdir/.settings le fait, en fonction de la façon dont vous prévoyez de gérer les normes et autres. Si vous pouvez honnêtement faire confiance à vos développeurs pour configurer leur environnement en fonction du standard, et que vous n'avez pas à personnaliser quoi que ce soit de spécial pour un projet, alors vous n'avez pas besoin de les mettre. Moi, je recommande de configurer chaque projet spécifiquement. Cela permet aux développeurs de travailler sur le contenu de plusieurs projets dans le même espace de travail sans avoir à modifier les paramètres par défaut dans les deux sens, et cela rend les paramètres très explicites, en remplaçant les paramètres par défaut par les standards du projet.

La seule difficulté est de s'assurer qu'ils restent tous synchronisés. Mais dans la plupart des cas, vous pouvez copier les fichiers .settings d'un projet à l'autre. S'il y en a que vous ne voulez pas voir dans le contrôle de source, faites l'équivalent de svn:ignore pour eux, si votre SCM le supporte.

Answer 5

Le fichier .classpath est définitivement un bon candidat pour être vérifié dans scm car le paramétrer à la main peut représenter beaucoup de travail et sera difficile pour les nouveaux développeurs qui se lancent dans le projet. Il est vrai qu'il peut être généré à partir d'autres sources, auquel cas il faut vérifier l'autre source.

Quant aux paramètres, cela dépend des paramètres. C'est une zone grise, mais certains paramètres sont presque obligatoires et il est pratique de pouvoir extraire un projet, de l'importer dans Eclipse et d'avoir tout configuré et prêt à fonctionner.

Dans notre projet, nous maintenons donc une copie du dossier .settings appelée CVS.settings et nous avons une tâche ant pour le copier dans .settings. Lorsque vous récupérez le projet depuis CVS, vous appelez la tâche ant 'eclipsify' pour copier les paramètres par défaut dans le nouveau dossier .settings. Lorsque vous configurez des paramètres qui sont nécessaires à tous les développeurs du projet, vous les fusionnez à nouveau dans le dossier CVS.settings et vous les livrez au CVS. De cette façon, la sauvegarde des paramètres dans SCM devient un processus conscient. Cela nécessite que les développeurs fusionnent ces paramètres dans leurs dossiers .settings de temps en temps lorsque des changements importants sont enregistrés. Mais c'est un système simple qui fonctionne étonnamment bien.