Теперь, как убедиться, что ваша система непрерывной сборки понимает изменения, внесенные в настройки eclipse, это еще одна проблема ... (У меня есть отдельный build.xml для ant, который я постоянно обновляю вручную)
ро собираюсь проверить самый первый коммит нового Java-проекта. Я работаю с Eclipse Ganymede, и несколько плагинов делают вещи немного проще.
Ранее я участвовал в проектах, в которых был зарегистрирован весь проект Eclipse. Очень удобно получить настройки проекта после проверки. Однако этот подход все еще не был беспроблемным:
Я сильно подозреваю, что некоторые файлы конфигурации Eclipse будут меняться без взаимодействия с пользователем (с тех пор, как я использовал Eclipse Europa), заставляя их выглядеть как измененные (как они были изменены, но не в интерактивном режиме), когда пришло время сделать коммит.Существуют настройки, уникальные для каждой машины разработки, а также глобальные настройки для всех разработчиков проекта. Хранить их отдельно было сложно.Когда-нибудь, если версия Eclipse будет отличаться от других, Eclipse рассердится и испортит конфигурацию проекта. Другой случай заключается в том, что он изменяет формат, чтобы он обновлялся, и, если зафиксирован, портит конфигурацию для других.Для этого конкретного проекта у меня есть еще одна причина не фиксировать файлы проекта:
Там могут быть разработчики, которые предпочитают NetBeans, которые присоединятся к проекту позже. Однако они не присоединятся в ближайшие месяцы.Как вы это организовали? Что вы проверяете в управлении версиями и что вы держите на улице? Что вы считаете лучшей практикой в такой ситуации?