Каков оптимальный способ организации общих сборок .net в SVN?

Question

Мы начинаем новый SOA-проект с большим количеством общих сборок .net. Код для этих сборок будет храниться в SVN.

На этапе разработки мы хотели бы иметь возможность кодировать эти сборки как единое решение с минимальным трением SVN.

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

Без создания ветвлений, тегов и автоматических сборок - это кошмар обслуживания, каков наилучший способ организации этих библиотек в SVN, который также хорошо работает с IDE VS 2008?

Вы настраиваете Trunk / Branches / Tags на каждом уровне библиотеки и пытаетесь каким-то образом спагетти все это вместе во время компиляции, или лучше для простоты сохранить все это как один большой проект с кодом, скопированным здесь и там? Есть ли решение с использованием externs?

Answer 1

В нашей компании мы создали репозиторий tools , а затем репозиторий project . Хранилище tools является хранилищем Subversion, организованным следующим образом:

/svn/tools/
   vendor1/
     too11/
       1.0/
       1.1/
       latest = a copy of vendor1/tool1/1.1
     tool2/
       1.0/
       1.5/
       latest = a copy of vendor1/tool2/1.5
   vendor2/
     foo/
       1.0.0/
       1.1.0/
       1.2.0/
       latest = a copy of vendor2/foo/1.2.0

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

[Пояснение: это НЕ типичный исходный репозиторий - он предназначен для хранения определенных версий «установленных» образов. Таким образом, /svn/tools/nunit/nunit2/2.4 будет вершиной дерева каталогов, содержащего результаты установки NUnit 2.4 в каталог и импорта его в репозиторий инструментов. Источник и примеры могут присутствовать, но основное внимание уделяется исполняемым файлам и библиотекам, которые необходимы для использования инструмента. Если бы нам нужно было изменить инструмент поставщика, мы бы сделали это в отдельном хранилище и опубликовали результат в этом хранилище. ]

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

---

Репозиторий projects является стандартным репозиторием Subversion, со стволами, тегами и ветвями, как вы обычно ожидаете. Любой данный проект будет выглядеть так:

/svn/
  branches/
  tags/
  trunk/
    foo/
      source/
      tools/
      publish/
      foo-build.xml (for NAnt)
      foo.build (for MSBuild)

В каталоге инструментов есть набор свойств Subversion svn: externals , который связывает в соответствующей версии (либо в конкретной версии, либо в «последней») каждый инструмент или сборку, необходимую для этого проекта. Когда CruiseControl.NET создает проект 'foo', задача публикации заполняет каталог 'publish', поскольку сборка 'foo' предназначена для развертывания, а затем выполняет следующие команды subversion:

svn import publish /svn/tools/vendor2/foo/1.2.3
svn delete /svn/tools/vendor2/foo/latest
svn copy /svn/tools/vendor2/foo/1.2.3 /svn/tools/vendor2/foo/latest

Разработчики работают над своими проектами в обычном режиме и позволяют автоматизации сборки позаботиться о деталях. Обычное обновление Subversion будет использовать последние версии внешних инструментов, а также обновления проекта.

Если у вас много взаимозависимостей инструментов, вы можете настроить CruiseControl.NET (вручную) на запуск сборок для подчиненных проектов при изменении их зависимостей, но нам пока не нужно заходить так далеко.

Примечание. Все пути к хранилищам Subversion были сокращены для ясности. На самом деле мы используем Apache + SVN и два отдельных сервера, но вы должны адаптировать их по своему усмотрению.

Answer 2

То, что мы делали с общими сборками на этапе разработки (в проекте, в котором было много таких загрузок), - это то, что мы помещаем их в место общего сетевого ресурса (N Drive), и каждый разработчик ссылается на них оттуда.

Наш процесс сборки всегда обновляет этот ресурс до последних версий. Таким образом, фактические сборки никогда не должны были храниться в системе контроля версий. Только код.