Какие файлы 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игнорировались только для вашей рабочей области. Но не лишайте всех других пользователей общего определения проекта Eclipse, которое они могут быстро импортировать в свое рабочее пространство Eclipse, просто потому, что у вас есть одно дополнительное определение, которое будет соответствовать только вашим потребностям на данный момент.
В настоящее время я работаю над проектом, в котором файлы .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 на новую машину разработчика.
Если вы работаете в команде, я думаю, что следующие кандидаты очень хороши для контроля версий:
commonвкладке выберитеSave as > shared file. Это напрямую помещает его в папку проекта, поэтому его можно выполнить с остальной частью проекта.