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

Base
    Libraries  
    Assemblies  
    Workbooks  
        Workbook1  
        Workbook2

每个工作簿都是其自己的解决方案，并且这些工作簿解决方案仅引用文件夹结构中的程序集。我的问题是我们如何布置源代码管理？我们会在基础上启动存储库吗？还是为每个工作簿解决方案创建一个存储库？我们会重新排列文件夹吗？

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

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

我会很感激见解，因为我很新鲜。

添加信息：当前，我个人使用Mercurial，但除非我可以对其他事项提出令人信服的论点，否则该项目可能会转移到StarTeam。

解决方案

我们没有在问题中提到我们正在使用哪种源代码控制。因为这听起来好像不需要限制外部开发人员对存储库其余部分的访问权限，所以我不会为建立多个存储库而烦恼。我会假设，除非代码遇到数百万行的大小，否则存储库大小不会成为问题。

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