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

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

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

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

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

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

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

Они найдены в

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рассматривать:

.classpath
.project
.launch

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

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

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

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

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