具有共享库的多个项目/解决方案的源代码控制答案

【问题标题】：Source Control for multiple projects/solutions with shared libraries具有共享库的多个项目/解决方案的源代码控制
【发布时间】：2010-09-13 03:58:27
【问题描述】：

我目前正在开展一个项目，将多个 Excel VBA 驱动的工作簿转换为 VSTO 解决方案。所有的工作簿都将共享一些类库和第三方程序集，实际上大部分工作都是在类库中完成的。我目前的文件夹结构是这样布局的。

Base
    Libraries  
    Assemblies  
    Workbooks  
        Workbook1  
        Workbook2

每个工作簿都是自己的解决方案，工作簿解决方案只是引用文件夹结构中的程序集。我的问题是您将如何布置源代码控制？你会在基地启动存储库吗？或者您会为每个工作簿解决方案创建一个存储库吗？你会重新排列文件夹吗？

现在我们已经完成了最初的开发，我们即将有一群外部开发人员加入该项目，以帮助我们转换其余的工作簿，我真的很喜欢他们能够签出的想法来自基本目录并准备好所有依赖项。我还担心在一个源代码控制存储库下拥有 20 多个解决方案/项目会带来其他问题。

对于加入该项目的人来说，我希望一切都尽可能简单，但我不想牺牲长期可用性。在我的脑海中，我一直在反复讨论，一个存储库或每个解决方案一个存储库哪个更简单？

我很感激您的见解和见解，因为我是新人。

附加信息：目前，我个人使用 Mercurial，但该项目可能会转移到 StarTeam，除非我能为其他东西提出一些令人信服的论据。

【问题讨论】：

【解决方案1】：

你没有在你的问题中提到你正在使用什么源代码控制。因为听起来您不需要限制外部开发人员访问存储库的其余部分，所以我不会费心设置多个存储库。我假设除非您的代码运行到数百万行大小，否则存储库大小不是问题。

这完全取决于您的版本控制系统支持什么功能。在 subversion 中，您可以将其他文件夹声明为外部文件夹并为该文件夹的内容提供文件 URL，这将导致 subversion 将该文件夹作为单独的存储库处理，即使它位于您的文件夹结构中。

【讨论】：

我想我明白了，使用外部组件使 subversion 从外部链接获取最新版本的依赖项。因为我希望人们能够加载类库进行调试，所以我应该在顶部启动存储库。如果我不这样做，我可以使用外部来导入依赖项。