Какие файлы Eclipse принадлежат управлению версиями?

Какие файлы Eclipse подходят для установки под контролем источника, за исключением источников?

В моем проекте, в частности, мне интересно:

.metadata/*
Проект-Dir/.project
Проект-Dir/.classpath
project-dir/.settings/*

Если есть какие-либо из них, для которых это зависит, пожалуйста, объясните свои рекомендации.

Ответ 1

Метаданные не должны управляться в исходном управлении. Они содержат в основном данные, относящиеся к вашей рабочей области.

Единственным исключением являются 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)

alt text

Ответ 2

В настоящее время я работаю над проектом, в котором у нас есть файлы .project и .cproject под контролем источника. Идея заключалась в том, что настройки, связанные с библиотечными путями и директивами ссылок, будут распространяться по всей команде.

На практике это не сработало очень хорошо, слияния почти всегда возвращаются в конфликтное состояние, которое нужно деконфликтять за пределами затмения, а затем проект закрыт и вновь откроется, чтобы изменения вступили в силу.

Я бы не рекомендовал держать их в управлении версиями.

Ответ 4

Некоторые проекты, подобные тем, которые используют Maven, любят создавать файлы .project на основе POM.

Тем не менее, кроме этого -. metadata НЕ должны находиться в исходном управлении. Ваш проект должен будет определить, работает ли projectdir/.settings, исходя из того, как вы планируете управлять стандартами и т.д. Если вы можете честно доверять своим разработчикам настроить свою среду на основе стандарта, и вам не нужно настраивать что-либо особенное для любого проекта, тогда вам не нужно вводить их. Я рекомендую настроить каждый проект специально, Это позволяет разработчикам работать с несколькими проектами в одном рабочем пространстве без необходимости изменять настройки по умолчанию взад и вперед, и это делает настройки очень явными, переопределяя все их настройки по умолчанию в соответствии со стандартами проекта.

Только сложная часть - убедиться, что все они остаются в синхронизации. Но в большинстве случаев вы можете скопировать файлы .settings из проекта в проект. Если в исходном элементе есть какие-либо функции, которые вы специально не хотите, выполните эквивалент установки svn: ignore для них, если ваш SCM поддерживает его.

Ответ 5

Файл .classpath окончательно является хорошим кандидатом для проверки на scm, поскольку его вручную может быть большой работой, и для новых разработчиков будет сложно попасть в проект. Это правда, что он может быть создан из других источников, и в этом случае вы должны проверить другой источник.

Что касается настроек, это зависит от настроек. Это серая область, но некоторые настройки почти обязательны, и удобно иметь возможность проверить проект, импортировать его в Eclipse и настроить все и хорошо.

В нашем проекте мы поэтому сохраняем копию папки .settings с именем CVS.settings, и у нас есть задача ant, чтобы скопировать ее в .settings. Когда вы получаете проект из CVS, вы вызываете задачу "eclipsify" ant, чтобы скопировать настройки по умолчанию в новую папку .settings. Когда вы настраиваете параметры, которые необходимы всем разработчикам проекта, вы объединяете их обратно в папку CVS.settings и фиксируете это с помощью CVS. Таким образом, сохранение настроек в SCM становится сознательным процессом. Это требует, чтобы разработчики время от времени объединили эти настройки в свои папки .settings, когда были внесены большие изменения. Но это простая система, которая работает на удивление хорошо.

Ответ 6

Я бы не сказал ни одного из них. Скорее всего, они содержат информацию, относящуюся только к вашей рабочей станции (я думаю о путях для библиотек и всех). Также, если кто-то из вашей команды не использует Eclipse?

Ответ 7

Рассмотрим:

.classpath
.project
.launch

Эти ДОЛЖНЫ находиться в управлении версиями, если вы придерживаетесь путей, связанных с проектом. Это позволяет другим разработчикам проверять проект и сразу же начать работать без необходимости проходить всю боль, вызванную настройкой, и другие разработчики также прошли через.

Возможно, у вас может возникнуть соблазн включить .metadata в управление версиями, так что разработчики Eclipse могут проверить всю рабочую область и предварительно сконфигурировать ее со всеми подходящими проектами, но она включает в себя множество пользовательских данных, которые в любое время работают на нее, он изменится, поэтому я бы посоветовал НЕ ВКЛЮЧАТЬ. metadata. Легко построить локальную рабочую область, просто импортировав все существующие проекты Eclipse.

Ответ 8

Я потратил слишком много часов на настройку параметров рабочего пространства eclipse для новых коллег (и я). В конечном итоге я решил копировать свои собственные метаданные на новую машину разработчика.

Если вы работаете над командой, то я думаю, что следующие очень хорошие кандидаты, чтобы поддерживать контроль версий:

  • Установленные JRE и их имена
  • Среда выполнения сервера
  • Шаблоны редактора Java
  • Сочетания клавиш управления версиями
  • Параметры плагина, которые не предоставляют конкретные настройки проекта
  • Настройки Maven
  • Предварительно настроенные перспективы
  • ...