Типичная структура репо SVN представляется неоптимальной для непрерывной интеграции

Question

Я создал наш SVN-репозиторий, как предлагает книга Subversion, и это также, как мои предыдущие компании делали это. Это выглядит примерно так:

/trunk
/branches
/tags
/extlibs
/docs

, где первые три довольно очевидны, а extlibs для сторонних сборок, которые мы обычно не перекомпилируем.

Все это прекрасно работает для повседневной работы.

Теперь я установил TeamCity, и у меня запущены сборки, модульные тесты, покрытие кода и анализ кода. Все отлично, за исключением того факта, что эта структура кода приводит к загрузке слишком большого количества кода.

Так что, вот мой уловка 22, на мой взгляд: глупо загружать все вышеупомянутые папки из репозитория SVN, когда мне нужны только / trunk и / extlibs. Но я могу указать только одну папку репо для загрузки в настройках TeamCity VCS. Таким образом, другая возможность - поместить папку / extlibs в / trunk, но для компиляции веток / extlibs также придется войти во все из них (поскольку я обычно разветвляю транк, а не отдельные подпапки ... и это может показаться бесконечно более злым, поскольку / extlibs на самом деле может быть больше, чем / trunk и / branch, со всеми хранящимися там двоичными файлами ...

Ребята, у вас есть предложения для меня? Спасибо!

Answer 1

Установить TeamCity для загрузки только /trunk. Сделайте /trunk/extlibs внешним, указывающим на /extlibs. Сделайте то же самое для всех /branches. Это позволило бы вам совместно использовать /extlibs между /trunk и всеми /branches, сохраняя при этом одну корневую папку для каждого из них.

Обновление : Когда я сказал сделать /extlibs внешним в /trunk/extlibs, я имел в виду свойство SVN externals. Предполагая, что ваш SVN-сервер svn://yoursvnserver/svn, вы можете сделать это с помощью следующей команды svn:

svn.exe propset svn: externals svn: // yoursvnserver / svn / trunk -F externals_defs.txt

Вы можете обратиться к svn.exe help propset для получения более подробной информации о формате файла, но в простейшей форме он будет иметь одну строку, подобную этой:

extlibs svn://yoursvnserver/svn/extlibs

Как только вы установите внешнее свойство SVN в транке, вы его подтвердите. С этого момента все, кто получит /trunk (включая TeamCity), получат /trunk/extlibs копию /extlibs. Конечно, вам придется немного изменить ссылки, чтобы они указывали на /trunk/extlibs, чтобы ваша сборка содержалась в дереве /trunk.

Answer 2

Я бы хотел добавить небольшой ответ.Все ответы здесь о том, как поручить Subversion хранить «текущую» копию внешних библиотек как часть магистрали, в основном являются правильным способом продвижения вперед в этом конкретном случае.

Однако, если по какой-то причине вывы хотите сделать это из частей репозитория в TeamCity, как вы и просили, вы тоже можете это сделать.

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

Нажмите ссылку "изменить правила извлечения" справа в корневой сетке VCS для этой конфигурации сборки и введите следующее (в соответствии с вашим примером):

-:.
+:trunk
+:extlibs

Сначала все помечается как «не опускаться», как файлы, так и подпапки корневого каталога, а затем помечается как транк и extlibs как «выпадающий».Подробнее о правилах оформления заказа можно прочитать здесь .

Answer 3

Я бы сказал, что помещать экстлибы в ствол - это хорошая идея, которая решает не только вашу проблему, но и другую.

Что происходит, когда вам нужно выпустить предыдущую помеченную сборку, но с тех пор вы обновили некоторые библиотеки в extlibs? Вы должны пролистать историю, чтобы найти версию extlibs, которая была актуальна, когда эта сборка была помечена.

Answer 4

Похоже, у вас есть две разные проблемы, которые вам нужно решить:

1. Как настроить VCS для вашей конфигурации сборки
2. Как обращаться с внешними библиотеками

Для вашего VCS оставьте настройку как есть - в корне вашего хранилища. В каждую конфигурацию сборки вы можете добавить правила оформления заказа , чтобы сократить время оформления заказа до нужных папок.

Например, вы можете использовать следующую папку, чтобы сделать папку багажника корневой папкой оформления заказа:

+:trunk=>.

Или для ветки вы можете сделать что-то вроде:

+:branches/featureset=>.

При желании вы можете добавить несколько правил оформления заказа, включая добавление любых файлов / папок из папки extlib:

+:extlibs/dependency-2.5.3=>.libs/dependency1

Вы даже можете удалить файлы / папки, используя правила оформления заказа:

-:trunk/files-not-needed 

Для ваших внешних библиотек , как указано в других ответах, вы можете включать внешние папки, используя SVN. Тем не менее, я бы не стал жестоко обращаться с включением всей папки extlibs. Включайте только те версии библиотеки, которые вам нужны для создания проекта. Также убедитесь, что ваши папки extlibs хорошо защищены от изменений. Благодаря детальному изучению внешних факторов вы можете избежать попыток создать старую версию, поскольку ваш проект будет связан с правильной версией. Если вы активировали триггерные сборки, вы также избежите изменения библиотеки, запускающего сборку. Например, вы можете настроить ваш snv: external libs следующим образом:

libs/dependency1 svn://yoursvnserver/svn/extlibs/dependency-2.5.3
libs/dependency2 svn://yoursvnserver/svn/extlibs/dependency-rc-2.4

Answer 5

Один из подходов - хранить экстлибы в их собственной структуре «проекта». Рассматривайте их как отдельный проект, на который ссылается ваш основной проект, а не как часть основного проекта. Затем установите TeamCity для «сборки» этих двоичных файлов (то есть просто для их извлечения), когда они будут изменены. Поскольку ваш основной проект зависит от этих двоичных файлов, при их сборке он должен запускать сборку проектов, которые зависят от них. Таким образом, вы не извлекаете двоичные файлы каждый раз, когда готовитесь к созданию основного проекта, а только после их перекомпиляции и передачи в SVN.