Какие файлы Eclipse находятся под контролем версий?
Какие файлы Eclipse целесообразно поставить под контроль исходного кода, кроме источников, очевидно?
В моем проекте, в частности, мне интересно о:
.metadata / *
Проект-Dir /.project
Проект-Dir /.classpath
проект-Dir/.settings/*
Если есть какие-либо из них, от которых это зависит, пожалуйста, объясните ваши рекомендации.
9 ответов
Метаданные не должны управляться в системе контроля версий. Они содержат в основном данные, относящиеся к вашей рабочей области.
Единственным исключением является .launch XML-файлы (определение модуля запуска).
Они найдены в
[eclipse-workspace]\.metadata\.plugins\org.eclipse.debug.core\.launches
И они должны быть скопированы в каталог вашего проекта: когда ваш проект обновляется, эти конфигурации будут отображаться в диалоговом окне "Выполнить настройку".
Таким образом, этими файлами параметров запуска можно также управлять в SCM.
(Предупреждение. Снимите флажок "Удалить конфигурации при удалении связанного ресурса" на панели предпочтений " Конфигурация запуска / запуска / запуска": обычно выполняется мягкое удаление проекта для его повторного импорта - для принудительной повторной инициализации Затмение метаданных. Но эта опция, если выбрана, удалит ваши подробные параметры запуска!)
project-dir/.project
project-dir/.classpath
project-dir/.settings/*
должно быть в вашем СКМ (особенно .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, вы вызываете задачу "eclipsify" и копируете настройки по умолчанию в новую папку.settings. Когда вы настраиваете параметры, которые нужны всем разработчикам проекта, вы объединяете их обратно в папку CVS.settings и фиксируете это в CVS. Таким образом, сохранение настроек в SCM становится сознательным процессом. Требуется, чтобы разработчики время от времени объединяли эти настройки в свои папки.settings, когда регистрируются большие изменения. Но это простая система, которая работает на удивление хорошо.
Я бы сказал, ни один из них. Скорее всего, они содержат информацию, которая имеет отношение только к вашей рабочей станции (я думаю о путях для библиотек и все). А что если кто-то в вашей команде не использует Eclipse?
Рассматривать:
.classpath
.project
.launch
Они ДОЛЖНЫ быть в управлении версиями, если вы придерживаетесь относительных к проекту путей. Это позволяет другим разработчикам сразу проверить проект и начать работу, не испытывая при этом всей сложности установки, которую пережили и другие разработчики.
У вас может возникнуть желание включить.metadata в систему управления версиями, чтобы разработчики Eclipse могли проверить всю рабочую область и предварительно сконфигурировать ее для всех нужных проектов, но она включает в себя множество специфической для пользователя информации, которую каждый раз, когда над ней кто-то работает, она будет изменить, поэтому я бы посоветовал НЕ ВКЛЮЧАТЬ. метаданные. Создать локальное рабочее пространство легко, просто импортировав все существующие проекты Eclipse.
Я потратил слишком много времени на настройку параметров рабочего пространства Eclipse для новых коллег (и для себя). В конечном итоге я скопировал свои собственные.metadata на новую машину разработчика.
Если вы работаете в команде, то я думаю, что следующие очень хорошие кандидаты для контроля версий:
- Установленные JRE и их названия
- Среды выполнения сервера
- Шаблоны редактора Java
- Сочетания клавиш управления версиями
- Настройки плагина, которые не предоставляют специфические настройки проекта
- Настройки Maven
- Предварительно настроенные перспективы
- ...
Я не пытался помещать что-либо в .metadata под контроль версий, но я использую контроль версий для этих файлов уже десять лет:
project-dir/.project
project-dir/.classpath
project-dir/.settings/*
Основная причина в том, что Eclipse иногда повреждает эти файлы. Без контроля версий вы получите странные и трудно отслеживаемые ошибки. С контролем версий вы можете сразу увидеть «Почему он пытается развернуть тестовые классы???» или «Почему Maven и Eclipse используют один и тот же путь к классам?» (ведущий к https://bugs.eclipse.org/bugs/show_bug.cgi?id=430605).
Благодаря контролю версий вы можете видеть, когда это происходит, и легко вернуться к рабочему набору файлов конфигурации.
Если вы используете m2e: теперь вы можете импортировать проект с помощью быстрого «Импортировать существующий проект» вместо медленного «Импортировать проект Maven».
Недостатком этого подхода является то, что Eclipse, по-видимому, случайным образом изменяет некоторые из этих файлов. Большинство плагинов поддерживают их стабильность, но некоторые используют HashMap вместо, скажем, LinkedHashMap, поэтому порядок элементов постоянно меняется. Это означает, что при фиксации есть дополнительный шаг: сначала проверьте любые измененные настройки и обработайте их.
Это также означает, что вся команда должна согласовать некоторые стандарты: Например, какие предупреждения должны быть включены. Интересно, что многие люди видят в этом дополнительную проблему — как будто они не работают вместе.
По моему опыту, на стабилизацию этих файлов уходит пара недель. Отчасти потому, что вы постепенно научитесь настраивать Eclipse, отчасти потому, что люди узнают, чего трогать нельзя. Вы можете думать об этом как о потерянном времени или времени, потраченном на улучшение качества вашей рабочей среды (например, на то, чтобы на вашем столе не было беспорядка).
Существует бонусное преимущество «сначала зафиксировать настройки»: он заставляет людей фиксировать чаще и небольшими частями (т. е. больше похоже на «одну мысль за раз» вместо «по каждой функции плюс тысячу других, не связанных между собой мыслей»). вещи, на которые я только что случайно наткнулся... над чем я снова работал?").
Как опытный разработчик, я предпочитаю метод работы «небольшие коммиты»; просто легче оставаться на правильном пути, и вы склонны сортировать свои мысли и изменения на более мелкие, более управляемые шаги. Это помогает снизить уровень сложности. Каждый может жонглировать одним мячом, никто не может жонглировать двадцатью.
PS: Для некоторых файлов настроек у меня есть модульные тесты, чтобы убедиться, что известные ошибки не появляются, например, «попытка развернуть тесты» в WTP. Это помогает на начальном этапе «зафиксировать все, я слишком занят».