svn中的组织解决方案

如何在SVN存储库（或多个存储库）中组织多个相关的Visual Studio解决方案/项目

例如，我有两个应用程序（解决方案），它们共享几个常见项目：

+ Application_1
  - Company.Core
  - Company.Connections
  - Company.Data
  - Company.A1.DAL
  - Company.A1.BL
  - Company.A1.UX

+ Application_2
  - Company.Core
  - Company.Connections
  - Company.Data
  - Company.A2.DAL
  - Company.A2.BL
  - Company.A2.UX

/svnroot
   /common
      /trunk
         /Company.Core
         /Company.Connections
         /Company.Data
   /app1
      /trunk
         /A1.DAL
         /A1...
   /app2
      /trunk
         /A2.DAL
         /A2...

对不对，应用程序_1和应用程序_2共享相同的SVN根，因为它们使用公共项目：

+ Application_1
  - Company.Core
  - Company.Connections
  - Company.Data
  - Company.A1.DAL
  - Company.A1.BL
  - Company.A1.UX

+ Application_2
  - Company.Core
  - Company.Connections
  - Company.Data
  - Company.A2.DAL
  - Company.A2.BL
  - Company.A2.UX

/svnroot
   /common
      /trunk
         /Company.Core
         /Company.Connections
         /Company.Data
   /app1
      /trunk
         /A1.DAL
         /A1...
   /app2
      /trunk
         /A2.DAL
         /A2...

这样做的原因是确保任何版本都具有公共文件夹中最新的可用程序集，并且签出在每台计算机上始终一致

所以我想知道的是：

• 每个解决方案都应该有自己的存储库吗
• 如果是，我如何共享常见项目并确保它们是最新的
• 我是否将公共程序集添加为已生成的依赖项（.dll），并将它们分别提交到每个解决方案存储库？如何使这些构建自动化

---

如何设置存储库完全取决于您自己，以及它如何为您的组织工作。我已经看到了几种方法，多年来，没有找到可靠的建议

编辑

最后一部分写得不好。我所说的“没有可靠的建议”是指没有一条建议说“你应该按照如下方式构建你的存储库…”所有建议都是“这对我们来说是有效的”，并且每一种安排回购协议的方式都对他们有效，布局也各不相同。所以我的意思是“没有适用于每个组织的可靠建议”

结束编辑

但是，您的存储库的结构与我们的存储库非常接近。我们有数百个项目，根上有几个节点。所有这些都在同一个存储库中

和您一样，我们也有一个公共目录，其中包含具有公共函数的项目，我们将这些函数添加为对其他节点中解决方案中项目的引用。这是我们经过多次尝试和错误重组后得出的结论，也是对我们有效的，所以我对你们的结构表示赞许

回答你的具体问题

• 我认为您应该有一个存储库，它的结构与您描述的一样
• 这允许您在一次签出中获得代码，确保所有内容都易于维护并保持最新。只需添加您的参考，因为所有内容都在同一回购协议中
• 最后，我们的一般经验法则是，始终在必要时添加对项目的引用，并且不要签入二进制文件，除非您需要一个公共dll并且没有源代码（例如第三部分组件）。例如，我们在“公共”文件夹中的“共享dll”中有Microsoft.AntiXss dll和Idunno.Anti-Csrf dll

---

作为旁注，这种结构还可以轻松地设置构建服务器。当我们设置CruiseControl.NET构建服务器时，我们让它进行一次签出，并通过指向.sln文件构建所有内容，就像在visual Studio中一样。通过一次回购并遵循我刚才制定的指导原则，我们的构建非常容易。

非常感谢，我认为我们做了一些非常糟糕的事情，但所有这些都是正确的观点。我不想签入二进制文件，如果我将我们的回购协议拆分为多个回购协议，这可能是必要的。