При работе с Eclipse я должен добавить рабочую область в систему контроля версий? - PullRequest
11 голосов
/ 15 сентября 2009

Я единственный разработчик в этом проекте.

Ответы [ 6 ]

14 голосов
/ 15 сентября 2009

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

8 голосов
/ 15 сентября 2009

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

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

  • Java-> Стиль кода-> Форматер
  • Java-> Стиль кода-> Очистить
  • Java-> Стиль кода-> Шаблоны кода
  • General-> Editors-Text Editors-Spelling-Dictionary
  • Любые другие настройки, которые вы внесли в систему поддержки импорта / экспорта

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

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

5 голосов
/ 15 сентября 2009

номер

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

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

2 голосов
/ 15 сентября 2009

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

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

2 голосов
/ 15 сентября 2009

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

1 голос
/ 15 сентября 2009

Я поиграл с идеей (с Subversion), что у меня есть папка «MyProject_Eclipseproj», которая содержит только файлы и каталоги проекта Eclipse, с подпоркой svn: externals, которая вытягивает все файлы / каталоги «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 между версиями.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...