Храниение настроек проекта в VCS

добавить файлы настроек в ignore лист?

Хранение сферических настроек в VCS не нужно.

Или... Нет ты же не спрашиваешь, как заигнорить '.project'? Или да?

Я тупо сделал .project.in и .cproject.in, и самодельный configure, который генерирует из них .project и .cproject

> Хранение сферических настроек в VCS не нужно.

чтобы поубавить градус сферичности, у нас есть pom.xml (основа проекта), но плагин m2eclipse не понимает формат pom'а до конца. Поэтому нужно некоторые настройки хранить в эклипсовом проекте. И это очень важные настройки, типа путей к коду.

Или... Нет ты же не спрашиваешь, как заигнорить '.project'? Или да?

1) я правильно понимаю, что если заигнорить .project, то входящие изменения .project'а из репозитория тоже будут игнорироваться?

2) нужно игнорировать не все изменения .project'а, а только _неважные_ изменения. Полное игнорировае .project'а приведет к тому, что пользователь никак не сможет закоммитать изменения.

а есть ли в эклипсе какой-нибудь механизм, который позволял бы разруливать этот configure автоматически на этапе импорта?
У нас сейчас всё хранится в pom.xml, а техлид - зверь, ему проще отказаться от дополнительных возможностей при переходе на .project, чем отказаться от автоматичности (которая достигается хранением ВСЕГО в pom.xml и генерации проекта эклипсы с помощью импорта из гуёв)

> а есть ли в эклипсе какой-нибудь механизм, который позволял бы разруливать этот configure автоматически на этапе импорта?

Я вообще не понимаю, почему ты говоришь об импорте. Импорт - разовая операция, делается один раз за всю жизнь кода в репозитории.

хранением ВСЕГО в pom.xml и генерации проекта эклипсы с помощью импорта из гуёв

Чем дальше, тем страньше. Что ты называешь «импортом» - прогон вашей гуевой тулзы?

> Импорт - разовая операция, делается один раз за всю жизнь кода в репозитории.

1) проект может пересобираться без гуёв (в виде Эклипсы), а из консоли. Пересобираться, конечно, мавеном. При этом нужно чутко понимать, что бОльшую часть настроек нужно хранить в Мавене, а в Эклипсе - только косяки m2eclipse и прочих плагинов.

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

Что ты называешь «импортом» - прогон вашей гуевой тулзы?

File -> Import -> Existing Project или File -> Import -> Existing Maven Project или еще какой-нибудь Project

> у нас есть pom.xml

но плагин m2eclipse не понимает формат pom'а до конца

Теперь всё понятно. Да, это действительно проблема. У себя решил так:

1) Первоначальный импорт/чекаут проекта из vcs достаточно редкая операция, поэтому класть .project под контроль версий неоправданно — разные предпочтения в команде и много конфликтов.

2) Записал скринкаст и доку в локальной вики по этой первоначальной настройке, куда что прописать, какие джарки скачать и т.д.

3) PROFIT! У каждого свои настройки, а начинающие работать с проектом не дёргают ветеранов по-мелочам.

>> Что ты называешь «импортом» - прогон вашей гуевой тулзы?

File -> Import -> Existing Project или File -> Import -> Existing Maven Project или еще какой-нибудь Project

Не, это для меня слишком сложно - я на жабе не пишу :) Думаю, без какого-то ручного труда тут не обойтись - скажем, пускать самописанный скрипт, который правит сгенерированный m2eclipse проект.

> пускать самописанный скрипт, который правит сгенерированный m2eclipse проект.

такой скрипт есть, и его даже не нужно писать заново: просто выполнить mvn eclipse:eclipse в корне проекта. Проблема в том, что это требует дополнительных действий.

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

ОК, запомнил, записал, мб заюзаю. Ждем ищо мнений)

Не используй этот жуткий m2eclipse, и добавь файлы проекты в игнор лист. Файлы проекта элементарно генерятся mvn eclipse:eclipse - ни разу не подводил.

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

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

В качестве костыля могу предложить хранить в репозитории «образец» проекта, при чекауте его просто переименуйте в оригинальное имя. Таким образом у каждого будет своя копия проекта, которая не будет комититься в репозиторий.

Кстати, тот же Code::Blocks разделяет настройки проекта (билды, файлы, параметры билдов, etc.). Все остальное, что может меняться каждым разработчиком независимо, хранится локально. И коммитить эти файлы в репозиторий не стоит.

Так же поступает и Xcode и, вроде, MS VS. Хотя особо одаренные мыше-программисты коммитят и эти файлы в репозиторий.

Проблема обычно решается Maven. Что глобально, то глобально в VCS, что локально то в профиль, который не в VCS, а у себя лежит. Если профиль суровый и серьезный, то можно его шаблон отдельно положить в VCS