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

Question

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

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

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

没有制作分支，标记和自动化构建维护噩梦，在SVN中组织这些库的最佳方式是什么，VS VS IDE也能很好地工作？

您是否在每个库级别都设置了Trunk/Branches/Tags，并在编译时以某种方式一起尝试将它们全部意大利面条一起粘贴在一起呢，还是更好地将它全部保存为一个代码复制到这里和那里以简化代码的大项目？有没有使用externs的解决方案？

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) 

的工具目录下有一个颠覆的svn：externals的属性集，在相应的版本链接的每个工具或组装的（或者是特定的版本或“最新”），其该项目需要。当'foo'项目由CruiseControl构建时。NET，发布任务将填充“发布”目录作为“富”组件预定部署，然后执行以下颠覆命令：

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 

开发人员在他们的项目中正常工作，并让构建自动化负责细节。正常的颠覆更新将拉动最新版本的外部工具以及项目更新。

如果你有很多工具相互依赖性，你可以配置CruiseControl.NET（手工）来触发它们的依赖关系发生变化时从属项目的构建，但我们并不需要那么做。

注意：为清晰起见，所有Subversion存储库路径都缩短了。我们实际上使用Apache + SVN和两个独立的服务器，但是您应该按照您认为合适的方式进行调整。

Answer 2

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

我们的构建过程将始终使用最新版本更新此份额。这样，实际的程序集永远不需要保存在源代码管理中。只有代码。