SVN Externals в другом SCM
На предыдущем рабочем месте мы использовали svn externals для обновления зависимых проектов при обновлении общего компонента. Это позволило легко увидеть все, что эти изменения были нарушены, а также автоматически обновить зависимые проекты до последней версии общего компонента без какого-либо вмешательства.
На новом рабочем месте мы используем cc.net с Surround Surm, и я пытаюсь найти что-то похожее в Surround. Я не нашел ничего похожего на внешние, только "общие файлы", но в отличие от внешних, общие файлы не позволяют указывать конкретную версию файла для внешнего.
Мне интересно, что другие люди делают в этих сценариях, чтобы опираться на свою непрерывную интеграцию и относиться к ней больше к интеграции, чем к серверу с непрерывной сборкой. Кто-нибудь знает инструмент или что-то, что делает "внешнее" поведение без использования SVN?
Я предполагаю наличие файла реестра xml, проекты которого зависят от того, от каких сборок и стоит ли использовать последнюю версию, но это кажется излишним.
1 ответ
Лично я считаю, что внешние элементы (или что-то подобное) в системе контроля версий немного странны и на самом деле довольно подвержены ошибкам. Я предпочитаю использовать для этой цели систему сборки (ant, make и т. Д.) Или систему непрерывной интеграции (hudson, build bot и т. Д.).
Используя систему сборки, я просто помещаю "общие части" туда, где их можно извлечь (с помощью wget, curl или просто cp), и имею цель, которая проверяет, является ли локальная (иногда даже проверенная в локальном проекте) копия до Дата.
Используя систему непрерывной интеграции, по крайней мере, Hudson может легко проверять каталоги из нескольких репозиториев для одной сборки. При использовании этого подхода я также извлекаю другой каталог для локальной разработки и помечаю его как "зависимость проекта" в eclipse.