it-roy-ru.com

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

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

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

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

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

239
sblundy

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

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

Они найдены в

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

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

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

(Предупреждение: не снимайте опцию "Удалить конфигурации при удалении связанного ресурса" в Run / Launching / Панель настроек Launch Configuration : обычно выполняется мягкое удаление проекта для его повторного импорта - для принудительного повторная инициализация метаданных Eclipse. Но эта опция, если выбрана, удалит ваши детальные параметры запуска!)

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

173
VonC

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

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

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

16
pdemarest

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

12
Diaa Sami

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

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

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

7
John Stoneham

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

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

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

6
Stijn de Witt

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

4
agnul

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

.classpath
.project
.launch

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

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

2
Alex McCarrier

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

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

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