Следует ли при работе с Eclipse добавлять рабочую область в систему управления версиями?

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


eclipse version-control
person AngryHacker    schedule 15.09.2009    source источник
comment
См. Также stackoverflow.com/questions/116121/   -  person VonC    schedule 16.09.2009

Ответы (6)


arrow_upward
14
arrow_downward

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

person akf    schedule 15.09.2009
comment
+1. тем не менее, они относятся к сфере проекта, а не к рабочему пространству. как насчет .metadata и других каталогов .xxxx непосредственно в папке рабочей области? - person van; 15.09.2009
comment
Я полностью не согласен с тем, что ваши файлы .classpath и .project должны быть добавлены в систему контроля версий. Они специфичны для вашего рабочего места. Если кто-то другой пытается проверить ваш проект, и у него eclipse настроен по-другому (другие плагины, настройки и т. Д.), Это может вызвать проблемы. Их можно легко воссоздать при проверке проекта, поэтому даже если в проекте участвует только один человек (прямо сейчас), нет необходимости хранить их. - person Ryan Guill; 15.09.2009
comment
Что такого специфичного для рабочей области в .classpath? Я могу понять часть .project, хотя я думаю, что вовлеченным людям намного проще иметь ее в VCS, но .classpath? Легко сделать его независимым от рабочего пространства (и обычно так оно и есть). - person Peter Štibraný; 15.09.2009

arrow_upward
9
arrow_downward

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

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

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

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

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

person Rich Seller    schedule 15.09.2009
comment
+1 к вам, сэр: в основном то, что я говорил в stackoverflow.com/questions/116121/, более года назад;) - person VonC; 16.09.2009
comment
жутко - почти год в день. - person akf; 16.09.2009

arrow_upward
5
arrow_downward

No.

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

Возможно, вас также заинтересуют ответы на этот вопрос: Чего НЕ ДОЛЖНО быть в исходном коде контроль?

person Thomas Owens    schedule 15.09.2009
comment
Не согласен, хотя бы какой-то элемент проекта ДОЛЖЕН находиться под SCM. Иначе как разработчики получают обновления проекта? Всегда есть какие-то метаданные проекта, которые стоит включить. - person Kendall Helmstetter Gelner; 15.09.2009
comment
Что вы имеете в виду обновления проекта? Кроме того, что, если я использую другую среду IDE? Или текстовый редактор (emacs? Vim?) Вместо IDE? Следует проверять только сценарии сборки, исходные файлы и зависимости. - person Thomas Owens; 15.09.2009
comment
van: Файлы, которые вы регистрируете, не зависят от редактора, системы контроля версий, языка программирования ... - person Thomas Owens; 15.09.2009
comment
Файлы, созданные IDE или процессом сборки (двоичные файлы, документация, созданная генератором), не должны проверяться в системе контроля версий. часто не такой хороший ответ, как кажется. Я не говорю, что вы должны фиксировать все, но часто есть артефакты, которые нелегко воссоздать. Т.е. Я обычно фиксирую файлы pdf / chm, сгенерированные из DocBook, так как вам нужно много разных инструментов для их воссоздания. Хотя это возможно, требуется время, чтобы найти все эти инструменты. - person Peter Štibraný; 15.09.2009
comment
Питер - Я никогда не использовал DocBook, и это может быть допустимым исключением (в конце концов, в каждом правиле есть исключения). Однако для большинства вещей у разработчиков должны быть все инструменты, необходимые для их создания. - person Thomas Owens; 15.09.2009

arrow_upward
2
arrow_downward

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

person nstehr    schedule 15.09.2009
comment
+1: @nstehr. Вы бы не добавили, например, файл org.eclipse.core.resources.prefs в папку .settings проекта? Зачем? - person van; 15.09.2009

arrow_upward
2
arrow_downward

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

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

person Vineet Reynolds    schedule 15.09.2009

arrow_upward
1
arrow_downward

Я играл с идеей (с 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 между версиями.

person Trevor Harrison    schedule 15.09.2009