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

В настоящее время я работаю над проектом, в котором у нас есть файлы .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 для новых коллег (и я). В конечном итоге я решил копировать свои собственные метаданные на новую машину разработчика.

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

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