Какие файлы Eclipse находятся под контролем версий? - PullRequest
239 голосов
/ 03 декабря 2008

Какие файлы Eclipse целесообразно поставить под контроль исходного кода, кроме источников, очевидно?

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

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

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

Ответы [ 8 ]

173 голосов
/ 03 декабря 2008

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

Единственным исключением являются .launch XML-файлы (определение модуля запуска).

Они найдены в

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

И они должны быть скопированы в каталог вашего проекта: при обновлении вашего проекта эти конфигурации будут отображаться в диалоговом окне «Выполнить настройку».

Таким образом, этими файлами параметров запуска можно также управлять в SCM.

(Предупреждение: снимите флажок «Удалить конфигурации при удалении связанного ресурса» в Выполнить / Запуск / Запуск конфигурации панель предпочтений: обычное мягкое удаление проекта для его повторного импорта - для принудительной повторной инициализации метаданных eclipse. Но эта опция, если флажок установлен, удалит ваши подробные параметры запуска!)

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

должно быть в вашем SCM (особенно .project и .classpath в соответствии с документацией Eclipse ).

Цель состоит в том, чтобы каждый мог оформить / обновить свое рабочее пространство SCM и импортировать проект Eclipse в рабочее пространство Eclipse.

Для этого вы хотите использовать только относительные пути в вашем .classpath, используя связанных ресурсов .

Примечание: лучше, если project-dir ссылается на «внешний» каталог проекта, а не на каталог, созданный в рабочей области eclipse. Таким образом, два понятия (рабочее пространство затмения и рабочее пространство SCM) четко разделены.


Как ipsquiggle упоминает в комментарии, и, как я уже упоминал в старом ответе , вы можете сохранить конфигурацию запуска как общий файл напрямую в каталоге вашего проекта. Вся конфигурация запуска может быть версионирована, как и другие файлы проекта.

(Из сообщения в блоге Совет. Создание и совместное использование конфигураций запуска из KD)

alt text

16 голосов
/ 03 декабря 2008

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

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

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

12 голосов
/ 23 января 2010

Ничего не стоит, что файлы конфигурации CDT не подходят для управления исходным кодом. Существует ошибка, которая регистрируется для файлов .cproject, которые меняются очень часто и вызывают конфликты, см. Совместное использование файлов cdt-project в репозитории всегда вызывает конфликты .

7 голосов
/ 07 декабря 2008

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

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

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

6 голосов
/ 23 июня 2010

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

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

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

4 голосов
/ 03 декабря 2008

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

2 голосов
/ 04 июня 2012

Рассмотрим:

.classpath
.project
.launch

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

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

1 голос
/ 21 апреля 2015

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

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

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