Должен ли я зафиксировать файлы, которые были изменены затмением

Question

Я унаследовал Java-проект в форме проекта Eclipse. После изменения конфигурации tomcat (с v6 на v7) subclipse попросил меня зафиксировать следующие файлы

• .classpath
• org.eclipse.core.prefs
• org.eclipse.common.project.facet.core.refs
• org.eclipse.common.project.facet.core.xml

Поможет ли их поручение членам моей команды или это испортит их рабочее пространство?

Каков наилучший практический подход к этому?

Answer 1

Вообще говоря, вы должны регистрировать (и фиксировать после изменений) все, что вносит вклад в сборку И, не подлежит повторной генерации путем повторной сборки И зависит от рабочей станции. (Последствия этого утверждения зависят от вашего процесса / процедуры сборки, которая предназначена.)

Это означает, что вы должны исключить все, что воссоздается при полной сборке и т. Д., Чтобы оно не регистрировалось (и не предлагалось для регистрации).

Answer 2

Как правило, вам следует избегать фиксации файлов, которые содержат пользовательские настройки и сведения о проекте, которые Eclipse и / или ваши плагины могут восстановить.

Но в некоторых случаях все немного мутно.Например, файл .classpath может быть основным источником пути сборки Eclipse;например, если у вас есть JAR-файлы в дереве вашего проекта, а не с помощью Maven.(В Maven плагин m2eclipse генерирует файл .classpath из информации о зависимостях в файле POM, и, следовательно, этот файл не должен регистрироваться.)

Кроме того, некоторые из аспектов аспекта являются пограничными.Например, в проектах с JSP и Javascripts я считаю необходимым изменить свойства фасетов, чтобы отключить сломанные валидаторы.И есть хороший повод для того, чтобы рассматривать эти изменения как часть проекта, а не как личные предпочтения.

Отделение предпочтений группы / проекта от личных предпочтений - это одна из областей, где (IMO) Eclipse серьезно несовершенен.

Answer 3

Да, хотя убедитесь, что пути являются относительными в рабочей области, а не абсолютными путями.Наличие этих файлов в рабочей области позволяет членам вашей команды работать в той же среде, что и вы.Это также значительно упрощает настройку новой среды разработки: вы просто извлекаете ее из системы контроля версий и в Eclipse используете «Импорт ...> Существующие проекты в рабочую область»

Как упоминалось в @adamdunne, эти файлы могут содержатьспецифические для окружающей среды пути.Однако, если вы будете осторожны, чтобы убедиться, что пути в вашем рабочем пространстве являются относительными, используя переменные и не импортируя внешние файлы jar, т. Е. Только включая файлы jar из проектов в рабочее пространство, то все будет в порядке.В моей рабочей области мы проверяем эти файлы, и у нас было гораздо меньше проблем с настройкой dev.окружающая среда с.

Answer 4

Лучше не фиксировать эти файлы, так как пути / настройки могут отличаться на разных рабочих станциях.

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

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

Если все фиксируют разные настройки IDE, представьте, какой это может вызвать беспорядок.

EDIT:

Больше объяснений;

Я работал в командах, которые люди использовали NetBeans, Eclipse, IDEA ... очень долго, и у них не было возможности изменить IDE. Это повлияет только на производительность этого человека.

Когда люди привыкают к своим IDE, они изучают сокращения, они знают, где искать некоторые функции (рефакторинг / сгенерировать метод установки getter / реализовать переопределение требуемых методов ....), поэтому, если вы заставите их использовать какую-то другую IDE, это будет просто усложняйте их и замедляйте для всего процесса. ИМХО и по моему опыту иметь гибкую кодовую базу всегда хорошо. Я парень по затмению и, вероятно, не хотел бы работать с какой-либо другой IDE, так как я знаю множество ярлыков, которые делают меня намного быстрее / проще, и эти сочетания отличаются в разных IDE.

Все файлы IDE могут быть автоматически восстановлены самой IDE, возможно, всего за пару кликов.

И в моем текущем проекте есть 3 разработчика, каждый из которых без проблем использует разные IDE eclipse (me), NetBeans, IDEA. Я не хочу видеть файлы конфигурации IDEA или NetBeans, которые не имеют смысла для затмения, когда я проверяю источник из репозитория. Точно так же и для них.

Answer 5

Эти файлы могут быть очень полезны для обмена конфигурациями между разработчиками. Альтернативой является либо использование Maven (что является огромной задачей для установленного проекта), либо постоянные устаревшие пошаговые инструкции и новые разработчики, занимающие полдня, пока они не смогут даже построить проект.

Однако вы должны позаботиться о том, чтобы эти конфигурации были переносимыми, то есть не содержали локальных путей. Это можно сделать с помощью использования относительных путей в рабочей области, переменных пути затмения и пользовательских библиотек.

Answer 6

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

Напротив, org.eclipse.core.prefs хранит (afaik) специфичные для проекта, но персональные предпочтения разработчиков, которые я бы не регистрировал.

С гранями я еще не работал в реальном проекте, поэтому не могу сказать. Но в целом, я думаю, это зависит от информации в файле и от того, как вы работаете.

Если вы не уверены, просто попробуйте. Если вы весь день сталкиваетесь с конфликтами в этих файлах, это намек, вы, возможно, не идеальный путь.

Answer 7

Эти файлы могут содержать пути, специфичные для среды, поэтому я бы рекомендовал не регистрировать их. В моем текущем проекте мы используем сценарии ant для создания проекта и первоначальной проверки всего нашего кода.

Answer 8

Что мы сделали, так это проигнорировали эти файлы, так как они могут испортить рабочее пространство других в проекте.

Игнорирование их также делает ваш проект чище, что мне всегда нравится.