在SVN中组织共享.net程序集的最佳方法是什么？

我们正在开始一个包含许多共享.net程序集的新SOA项目.这些程序集的代码将存储在SVN中.

在开发阶段,我们希望能够将这些组件编码为尽可能少的SVN"摩擦"的整个解决方案.

当项目进入更多维护模式时,程序集将在单个级别上维护.

在不进行分支,标记和自动构建维护噩梦的情况下,在SVN中组织这些库的最佳方法是什么,这也适用于VS 2008 IDE？

你是在每个库级别设置Trunk/Branches/Tags并尝试在编译时以某种方式将它们整合在一起,还是最好将它作为一个大项目保存在一起,代码复制在这里和那里为了简单起见？是否有使用外部的解决方案？

我们在公司所做的是建立一个工具库,然后是一个项目库.该工具库是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)

tools目录有一个Subversion svn:externals属性集,它链接到该项目所需的每个工具或程序集的相应版本(特定版本或"最新版本").当'foo'项目由CruiseControl.NET构建时,发布任务将填充'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和两个独立的服务器,但您应该根据需要调整它.