Теперь, как убедиться, что ваша система непрерывной сборки понимает изменения, внесенные в настройки eclipse, это еще одна проблема ... (У меня есть отдельный build.xml для ant, который я постоянно обновляю вручную)

ро собираюсь проверить самый первый коммит нового Java-проекта. Я работаю с Eclipse Ganymede, и несколько плагинов делают вещи немного проще.

Ранее я участвовал в проектах, в которых был зарегистрирован весь проект Eclipse. Очень удобно получить настройки проекта после проверки. Однако этот подход все еще не был беспроблемным:

Я сильно подозреваю, что некоторые файлы конфигурации Eclipse будут меняться без взаимодействия с пользователем (с тех пор, как я использовал Eclipse Europa), заставляя их выглядеть как измененные (как они были изменены, но не в интерактивном режиме), когда пришло время сделать коммит.Существуют настройки, уникальные для каждой машины разработки, а также глобальные настройки для всех разработчиков проекта. Хранить их отдельно было сложно.Когда-нибудь, если версия Eclipse будет отличаться от других, Eclipse рассердится и испортит конфигурацию проекта. Другой случай заключается в том, что он изменяет формат, чтобы он обновлялся, и, если зафиксирован, портит конфигурацию для других.

Для этого конкретного проекта у меня есть еще одна причина не фиксировать файлы проекта:

Там могут быть разработчики, которые предпочитают NetBeans, которые присоединятся к проекту позже. Однако они не присоединятся в ближайшие месяцы.

Как вы это организовали? Что вы проверяете в управлении версиями и что вы держите на улице? Что вы считаете лучшей практикой в ​​такой ситуации?

Ответы на вопрос(12)

Ваш ответ на вопрос