Quels fichiers Eclipse convient-il de placer sous contrôle de source, en dehors des sources évidemment?
Dans mon projet, en particulier, je me pose des questions sur:
.metadata / *
project-dir / .project
project-dir / .classpath
project-dir / .settings / *
S'il y en a qui en dépendent, veuillez expliquer vos directives.
Réponses:
Les métadonnées ne doivent pas être gérées dans le contrôle de code source. Ils contiennent principalement des données pertinentes pour votre espace de travail.
La seule exception concerne les .launchfichiers XML (définition du lanceur).
Ils se trouvent 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 est actualisé, ces configurations seront affichées dans la boîte de dialogue "Exécuter la configuration".
De cette façon, ces fichiers de paramètres de lancement peuvent également être gérés dans le SCM.
(Avertissement: décochez l'option "Supprimer les configurations lorsque la ressource associée est supprimée" dans le panneau de préférences Exécuter / Lancer / Lancer la configuration : Il est courant de supprimer en douceur un projet afin de le réimporter - pour forcer une réinitialisation du métadonnées d'éclipse. 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 .projectet .classpathselon la documentation Eclipse ).
L'objectif est que n'importe qui puisse extraire / mettre à jour son espace de travail SCM et importer le projet Eclipse dans l'espace de travail Eclipse.
Pour cela, vous souhaitez utiliser uniquement des chemins relatifs dans votre .classpath, en utilisant des ressources liées .
Remarque: il vaut mieux faire project-dirréférence à un répertoire de projet "externe", et non à un répertoire créé sous l'espace de travail eclipse. De cette façon, les deux notions (espace de travail Eclipse vs espace de travail SCM) sont clairement séparées.
Comme le mentionne ipsquiggle dans le commentaire, et comme je l'ai mentionné dans une ancienne réponse , vous pouvez réellement enregistrer la configuration de lancement en tant que fichier partagé directement dans votre répertoire de projet. Toutes les configurations de lancement peuvent ensuite être versionnées comme les autres fichiers de projet.
(Extrait de l'article de blog Astuce: Création et partage de configurations de lancement à partir de KD)
.projectpour le moment uniquement pour votre espace de travail. Mais ne privez pas tous les autres utilisateurs de la définition de projet Eclipse commune qu'ils peuvent importer rapidement dans leur espace de travail Eclipse, simplement parce que vous avez une définition supplémentaire qui ne répondrait qu'à vos besoins du moment.
Je travaille actuellement sur un projet où nous avons les fichiers .project et .cproject sous contrôle de source. L'idée était que les paramètres liés aux chemins de bibliothèque et aux directives de liaison se propageraient à travers l'équipe.
Dans la pratique, cela n'a pas très bien fonctionné, les fusions reviennent presque toujours dans un état conflictuel qui doit être déconflité en dehors de l'éclipse, puis le projet a été fermé et rouvert pour que les modifications prennent effet.
Je ne recommanderais pas de les garder sous contrôle de source.
Cela ne vaut rien que les fichiers de configuration CDT ne soient pas compatibles avec le contrôle de source. Un bogue a été déposé pour les fichiers .cproject qui changent très fréquemment et provoquent des conflits, voir Partager des fichiers de projet cdt dans le référentiel provoque toujours des conflits .
Certains projets, comme ceux utilisant Maven, aiment générer les fichiers .project basés sur les POM.
Cela dit, à part cela - les métadonnées ne doivent PAS être en 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, etc. Si vous pouvez honnêtement faire confiance à vos développeurs pour configurer leur environnement sur la base de la norme et que vous n'avez rien à personnaliser de spécial pour un projet, vous n'avez pas besoin de les mettre dedans. Moi, je vous recommande de configurer chaque projet spécifiquement . Cela permet aux développeurs de travailler sur plusieurs projets dans le même espace de travail sans avoir à modifier les paramètres par défaut d'avant en arrière, et rend les paramètres très explicites, remplaçant quels que soient leurs paramètres par défaut pour correspondre aux normes du projet.
La seule partie difficile 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 spécifiquement que vous ne voulez pas dans le contrôle de code source, faites l'équivalent de définir svn: ignore pour eux, si votre SCM le prend en charge.
Le fichier .classpath est définitivement un bon candidat pour vérifier dans scm car le configurer à la main peut être beaucoup de travail et sera difficile pour les nouveaux développeurs d'entrer dans le projet. Il est vrai qu'il peut être généré à partir d'autres sources, auquel cas vous devriez archiver l'autre source.
Quant aux .settings, cela dépend des paramètres. Il s'agit d'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 conservons donc une copie du dossier .settings appelé CVS.settings et nous avons une tâche ant pour la copier dans .settings. Lorsque vous obtenez le projet de CVS, vous appelez la tâche de fourmi «eclipsify» pour copier les paramètres par défaut dans le nouveau dossier .settings. Lorsque vous configurez les paramètres nécessaires à tous ceux qui développent le projet, vous les fusionnez dans le dossier CVS.settings et les validez dans CVS. De cette façon, l'enregistrement 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 de grands changements sont archivés. Mais c'est un système simple qui fonctionne étonnamment bien.
Je ne dirais aucun d'entre eux. Ils contiennent très probablement des informations qui ne concernent que votre poste de travail (je pense aux chemins d'accès aux bibliothèques et à tous). Et si quelqu'un de votre équipe n'utilise pas Eclipse?
Considérer:
.classpath
.project
.launch
Ceux-ci DEVRAIENT être en contrôle de version tant que vous vous en tenez à l'utilisation des chemins relatifs au projet. Cela permet aux autres développeurs de vérifier le projet et de commencer à travailler immédiatement sans avoir à passer par toutes les difficultés d'installation que les autres développeurs ont également connues.
Vous pourriez être tenté d'inclure des métadonnées dans le contrôle de version afin que les développeurs Eclipse puissent consulter un espace de travail entier et le préconfigurer avec tous les bons projets, mais il comprend de nombreuses informations spécifiques à l'utilisateur que chaque fois que quelqu'un y travaille, il le fera changer, donc je conseillerais de NE PAS INCLURE .metadata. Il est facile de créer un espace de travail local simplement en important tous les projets Eclipse existants.
J'ai passé trop d'heures à configurer les paramètres de l'espace de travail Eclipse pour les nouveaux collègues (et moi-même). J'ai fini par copier mes propres métadonnées sur la nouvelle machine de développement.
Si vous travaillez en équipe, je pense que les candidats suivants sont de très bons candidats à garder sous contrôle de version:
commononglet, choisissezSave as > shared file. Cela le dépose directement dans le dossier du projet, il peut donc être SCM avec le reste du projet.