Question

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

在开发阶段，我们希望能够将这些程序集编码为尽可能少的SVN“摩擦”的整个解决方案。

当项目进入更多维护模式时，程序集将保持在单独的级别上。

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

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

Answer 1

我们在公司所做的是设置工具存储库，然后设置项目存储库。工具存储库是一个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和两个独立的服务器，但您应该根据需要调整它。

Answer 2

我们在开发阶段（在一个有这些负载的项目中）对共享程序集所做的是，我们将它们放在一个地方的网络共享（N Drive）类型上，并且每个开发人员都从那里引用它们。 / p>

我们的构建过程将始终使用最新版本更新此共享。这样，实际的组件就不必保持在源代码控制中。只有代码。

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

2 个答案: