В настоящее время мы оцениваем Team Concert, и это включает в себя попытку развернуть собственную интеграцию между RTC и TeamCity.
Базовое упражнение заключается в том, что вы используете два API Java для создания плагина управления версиями . Есть небольшая горстка функций, которые вам нужно реализовать для команды city; наш прототип составляет около 1000 строк исходного текста, всего.
Самая большая проблема, по-видимому, заключается в том, что TeamCity ожидает, что вопрос getCurrentVersion () будет иметь согласованный, стабильный ответ, и это не похоже на правду о потоках и рабочих пространствах. На данный момент мы пытаемся обойти это, позволяя корню vcs создавать базовые линии, где это необходимо, но это имеет некоторые нежелательные побочные эффекты, когда вы пытаетесь работать с рабочей областью хранилища (в частности - размещение базовой линии также закрывается ( завершено) любые открытые наборы изменений ....
Кроме того, модель RTC позволяет вам делать прерывистые переходы в исходной системе - рабочее пространство, в настоящее время синхронизированное с базовой линией 20, может быть переназначено на базовую линию 25 или базовую линию 15, ни одна из которых не является частью предыдущей истории этого компонент в этом рабочем пространстве. Так что же мы должны сказать команде city, что ответ "исправить это в текущей версии" должен быть?
Есть вики-страница для изучения API RTC Java.
Один аспект, который задокументирован, но все равно сумел застать меня врасплох, заключается в том, что логика получения соединения с репозиторием по умолчанию предоставит вам общее соединение. Это делает беспорядок, когда у вас есть разработчики, пытающиеся создать корни VCS для их собственного рабочего пространства. Есть флаги, доступные, чтобы избежать совместного использования.