При работе с Eclipse следует добавить рабочую область в исходный элемент управления?

Ответ 1

Я бы не добавил полное рабочее пространство, но я бы добавил файлы .classpath и .project (а также источник, конечно), чтобы вы могли воссоздать проект, если нужно.

Ответ 2

Я бы не поручил всю рабочую область. Но стоит экспортировать настройки платформы и проверять их на исходный контроль (возможно, в отдельном проекте SCM, поскольку они не принадлежат ни одному отдельному проекту), если вы внесли несколько изменений, если вам нужно импортировать их в новое рабочее пространство.

Примерами этих файлов являются те настройки для:

• Java- > Code Style- > Formatter
• Java- > Стиль кода- > Очистка
• Java- > Code Style- > Code Templates
• Общие → Редакторы Текстовые редакторы - Словарь правописания
• Любые другие настройки, которые вы внесли значительные изменения в поддержку импорта/экспорта

Вы должны проверить первичные источники/ресурсы для проекта. Как отмечали другие, для типичного проекта это включает файлы .project и .classpath.

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

Ответ 3

Нет.

Файлы, которые генерируются IDE или процессом сборки (двоичные файлы, документация, создаваемая генератором), не должны проверяться в исходном элементе управления. Единственными файлами, которые должны быть проверены, являются ваши исходные файлы и внешние библиотеки, которые используются ваши исходные файлы.

Вас также могут заинтересовать ответы на этот вопрос: Что НЕ должно быть под контролем источника?

Ответ 4

Я бы выполнял только те проекты (ы), над которыми вы работаете, а также файлы .classpath и .project, а не всю рабочую область.

Ответ 5

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

Тем не менее, попытайтесь использовать Maven, чтобы файлы Eclipse.project и .classpath могли быть сгенерированы без необходимости их проверки.

Ответ 6

Я играл с идеей (с Subversion) наличия папки "MyProject_Eclipseproj", в которой содержатся только файлы проекта и каталоги Eclipse, с помощью svn: externals prop, который извлекает все файлы/каталоги MyProject.

Итак, макет будет выглядеть следующим образом:

/repos/trunk/MyProject
/repos/trunk/MyProject/build.xml
/repos/trunk/MyProject/src
/repos/trunk/MyProject/src/com
/repos/trunk/MyProject/src/com/mypackage
/repos/trunk/MyProject/src/com/mypackage/MyClass.java
/repos/trunk/MyProject_Eclipse_34 <- external prop goes here
/repos/trunk/MyProject_Eclipse_34/.settings/
/repos/trunk/MyProject_Eclipse_34/.project
/repos/trunk/MyProject_Eclipse_34/.classpath
/repos/trunk/MyProject_Eclipse_35 <- external prop goes here
/repos/trunk/MyProject_Eclipse_35/.settings/
/repos/trunk/MyProject_Eclipse_35/.project
/repos/trunk/MyProject_Eclipse_35/.classpath

Папка MyProject будет чистым кодом, без затмения затмения. В MyProject_Eclipse_Ver будут содержаться специальные файлы Eclipse и указатели для вставки кодовых папок. У вас также могут быть определенные папки для разных версий Eclipse, поэтому каждый разработчик не будет принудительно обновляться, если что-то изменилось в файле .settings или .project между версиями.