RTC с Eclipse: желательно ли хранить код в полностью настроенном проекте Eclipse?
Недавно моя проектная группа купила кодовую базу C/C++ у подрядчика, который не использует Eclipse. По сути, большое дерево /src, организованное для сборки с помощью Autotools, с несколькими сценариями сборки верхнего уровня, маскирующими некоторые сложности Autotools.
Разработчикам из нашей проектной команды удалось настроить код в Eclipse (Luna) как проект Autotools... но в настоящее время вызывает горе то, что, когда мы начинаем работать с этим кодом, проект CM также переходит на Jazz / RTC 5 (Формальный процесс, а не Agile) из ClearCase/ClearQuest.
Никто из нас не знает, должен ли код идти в репозиторий RTC в форме полностью настроенного проекта Eclipse, готового для использования разработчиками.
Как разработчик я читаю, что должен: если это не так, когда я загружаю код в рабочую область своего репозитория, я должен начать с добавления новых файлов.project, .cproject и.autotools "за кулисами" в добраться до проекта, в котором указаны необходимые мне пути включения, возможен анализ кода на C/C++ и (надеюсь) его можно заново настроить для сборки Autotools из Eclipse. Это также означает, что когда я возвращаю наборы изменений обратно, вероятно, придется использовать множество подверженных ошибкам обходных путей, чтобы избежать доставки специфичных для проекта настроек, которые не являются частью кодовой базы, как это задумано CM. Прямо сейчас это проводится как можно ближе к поставляемому (не затмеваемому) пакету подрядчика.
Я надеюсь, что любой может сказать мне, если это стандартная практика при использовании RTC с Eclipse - настраивать свой код в RTC в форме полностью настроенных, готовых к использованию проектов Eclipse. Язык, используемый в статьях, которые я нахожу, предполагает это, например, речь идет о "Найти и загрузить проекты Eclipse ", но ничего, что я вижу, не делает это явным.
2 ответа
в том, что любой может сказать мне, если это стандартная практика при использовании RTC с Eclipse, чтобы настроить свой код в RTC в форме полностью настроенных, готовых к использованию проектов Eclipse.
Это стандарт для любого инструмента контроля версий.
См. " Должен ли я хранить файлы моего проекта под контролем версий? " Или " .classpath а также .project - проверить контроль версий или нет? ".
РТК просто предлагают создать .project просто для ссылки на файлы компонента в рабочей области Eclipse (для удобства, чтобы облегчить исследование файла данного компонента RTC).
Но это отдельно от того, чтобы иметь полноценный .project, со многими дополнительными настройками, настроенными там.
Я не держу определенные файлы IDE под контролем версий.
По сути, у вас есть проект автоинструментов, поэтому все, что я делаю, это помещаю все исходные файлы автоинструментов (autogen.sh, configure.ac, Automake.am) под контроль версий.
У меня также есть пара сценариев для настройки автоинструментов под различные базовые конфигурации (configure-debug.sh, configure-release.sh).
Тогда каждый разработчик просто запускает сценарии, которые производят Makefiles,
Теперь они могут использовать любой IDE они хотят, основываясь на Makefiles, Каждый разработчик должен уметь работать с Makefile по крайней мере.
В Eclipse я создаю неуправляемый проект в стиле "Makefile" и подключаю Makefiles что производит автоинструмент.
Но проект не связан с затмением, он связан с любой средой, в которой работает автоинструмент. Разработчики могут использовать все, что угодно IDE они предпочитают.