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

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

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

В нашей компании мы создали репозиторий инструменты, а затем репозиторий проект. Репозиторий инструменты - это репозиторий 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 в каталог и его импорта в репозиторий инструментов. Исходный код и примеры могут присутствовать, но основное внимание уделяется исполняемым файлам и библиотекам, которые необходимы для использования инструмента. Если бы нам нужно было изменить инструмент поставщика, мы бы сделали это в отдельном репозитории и опубликовали бы результат в этом репозитории.

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

Репозиторий проекты - это стандартный репозиторий 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' предназначена для развертывания, а затем выполняет следующие команды подрывной деятельности:

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 (вручную), чтобы запускать сборки для подчиненных проектов при изменении их зависимостей, но нам пока не нужно заходить так далеко.

Note: All of the Subversion repository paths have been shortened for clarity. We actually use Apache+SVN, and two separate servers, but you should adapt this as you see fit.