Какие файлы Eclipse подходят для установки под контролем источника, за исключением источников?
В моем проекте, в частности, мне интересно:
.metadata/*
Проект-Dir/.project
Проект-Dir/.classpath
project-dir/.settings/*
Если есть какие-либо из них, для которых это зависит, пожалуйста, объясните свои рекомендации.
Метаданные не должны управляться в исходном управлении. Они содержат в основном данные, относящиеся к вашей рабочей области.
Единственным исключением являются XML файлы .launch (определение пусковой установки).
Они найдены в
[eclipse-workspace]\.metadata\.plugins\org.eclipse.debug.core\.launches
И они должны быть скопированы в каталог вашего проекта. Когда ваш проект будет обновлен, эти конфигурации будут отображаться в диалоговом окне "Запуск конфигурации".
Таким образом, эти файлы параметров запуска могут также управляться в SCM.
(Предупреждение: Do снимите флажок "Удалить конфигурации при удалении связанного ресурса" на панели предпочтений "Запуск/запуск/запуск": обычно для удаления нежелательных проектов рекомендуется импортировать он снова возвращается - для принудительной повторной инициализации метаданных затмения. Но этот параметр, если установлен, удалит ваши подробные параметры запуска!)
project-dir/.project
project-dir/.classpath
project-dir/.settings/*
должен быть в вашем SCM (особенно .project и .classpath в соответствии с Документация Eclipse).
Цель состоит в том, чтобы каждый мог проверить/обновить рабочее пространство SCM и импортировать проект Eclipse в рабочее пространство Eclipse.
Для этого вы хотите использовать только относительные пути в вашем .classpath, используя связанные ресурсы.
Примечание: лучше, если project-dir ссылается на "внешний" каталог проекта, а не на каталог, созданный в рабочем пространстве eclipse. Таким образом, два понятия (рабочее пространство eclipse и рабочее пространство SCM) четко разделены.
Как ipsquiggle упоминается в комментарии и как я уже упоминал в старом ответе, вы действительно можете сохранить конфигурацию запуска как общий файл непосредственно в каталоге проекта. Затем вся конфигурация запуска может быть версией, как и другие файлы проекта.
(Из сообщения блога Совет: создание и совместное использование конфигураций запуска от KD)
В настоящее время я работаю над проектом, в котором у нас есть файлы .project и .cproject под контролем источника. Идея заключалась в том, что настройки, связанные с библиотечными путями и директивами ссылок, будут распространяться по всей команде.
На практике это не сработало очень хорошо, слияния почти всегда возвращаются в конфликтное состояние, которое нужно деконфликтять за пределами затмения, а затем проект закрыт и вновь откроется, чтобы изменения вступили в силу.
Я бы не рекомендовал держать их в управлении версиями.
Не стоит ничего, что файлы конфигурации CDT не зависят от источника. Там ошибка, с которой файлы .cproject меняются очень часто и вызывает конфликты, см. Совместное использование файлов cdt-project в репозитории всегда вызывает конфликты.
Некоторые проекты, подобные тем, которые используют Maven, любят создавать файлы .project на основе POM.
Тем не менее, кроме этого -. metadata НЕ должны находиться в исходном управлении. Ваш проект должен будет определить, работает ли projectdir/.settings, исходя из того, как вы планируете управлять стандартами и т.д. Если вы можете честно доверять своим разработчикам настроить свою среду на основе стандарта, и вам не нужно настраивать что-либо особенное для любого проекта, тогда вам не нужно вводить их. Я рекомендую настроить каждый проект специально, Это позволяет разработчикам работать с несколькими проектами в одном рабочем пространстве без необходимости изменять настройки по умолчанию взад и вперед, и это делает настройки очень явными, переопределяя все их настройки по умолчанию в соответствии со стандартами проекта.
Только сложная часть - убедиться, что все они остаются в синхронизации. Но в большинстве случаев вы можете скопировать файлы .settings из проекта в проект. Если в исходном элементе есть какие-либо функции, которые вы специально не хотите, выполните эквивалент установки svn: ignore для них, если ваш SCM поддерживает его.
Файл .classpath окончательно является хорошим кандидатом для проверки на scm, поскольку его вручную может быть большой работой, и для новых разработчиков будет сложно попасть в проект. Это правда, что он может быть создан из других источников, и в этом случае вы должны проверить другой источник.
Что касается настроек, это зависит от настроек. Это серая область, но некоторые настройки почти обязательны, и удобно иметь возможность проверить проект, импортировать его в Eclipse и настроить все и хорошо.
В нашем проекте мы поэтому сохраняем копию папки .settings с именем CVS.settings, и у нас есть задача ant, чтобы скопировать ее в .settings. Когда вы получаете проект из CVS, вы вызываете задачу "eclipsify" ant, чтобы скопировать настройки по умолчанию в новую папку .settings. Когда вы настраиваете параметры, которые необходимы всем разработчикам проекта, вы объединяете их обратно в папку CVS.settings и фиксируете это с помощью CVS. Таким образом, сохранение настроек в SCM становится сознательным процессом. Это требует, чтобы разработчики время от времени объединили эти настройки в свои папки .settings, когда были внесены большие изменения. Но это простая система, которая работает на удивление хорошо.
Я бы не сказал ни одного из них. Скорее всего, они содержат информацию, относящуюся только к вашей рабочей станции (я думаю о путях для библиотек и всех). Также, если кто-то из вашей команды не использует Eclipse?
Рассмотрим:
.classpath
.project
.launch
Эти ДОЛЖНЫ находиться в управлении версиями, если вы придерживаетесь путей, связанных с проектом. Это позволяет другим разработчикам проверять проект и сразу же начать работать без необходимости проходить всю боль, вызванную настройкой, и другие разработчики также прошли через.
Возможно, у вас может возникнуть соблазн включить .metadata в управление версиями, так что разработчики Eclipse могут проверить всю рабочую область и предварительно сконфигурировать ее со всеми подходящими проектами, но она включает в себя множество пользовательских данных, которые в любое время работают на нее, он изменится, поэтому я бы посоветовал НЕ ВКЛЮЧАТЬ. metadata. Легко построить локальную рабочую область, просто импортировав все существующие проекты Eclipse.
Я потратил слишком много часов на настройку параметров рабочего пространства eclipse для новых коллег (и я). В конечном итоге я решил копировать свои собственные метаданные на новую машину разработчика.
Если вы работаете над командой, то я думаю, что следующие очень хорошие кандидаты, чтобы поддерживать контроль версий: