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

Question

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

/trunk 
/branches 
/tags 
/extlibs 
/docs 

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

Все это отлично подходит для повседневной разработки.

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

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

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

Answer 1

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

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

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

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

+:trunk=>. 

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

+:branches/featureset=>. 

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

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

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

-:trunk/files-not-needed 

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

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

Answer 2

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

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

svn.exe propset SVN: внешние СВН: // yoursvnserver/SVN/багажник -F externals_defs.txt

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

extlibs svn://yoursvnserver/svn/extlibs 

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

Answer 3

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

Answer 4

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

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

Answer 5

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

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

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

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

-:. 
+:trunk 
+:extlibs 

Это будет первый флаг все, как " не вытаскивайте ", как файлы, так и вложенные папки корня, а затем флаг и trunk и extlibs как" do pull the down ".

Вы можете узнать больше о checkout rules here.