我目前正在开发一个项目，将许多Excel VBA驱动的工作簿转换为VSTO解决方案。所有工作簿都将共享许多类库和第三方程序集，实际上大部分工作都是在类库中完成的。我目前的文件夹结构如此布局。
Base
Libraries
Assemblies
Workbooks
Workbook1
Workbook2
每个工作簿都是自己的解决方案，工作簿解决方案只引用文件夹结构中的程序集。我的问题是你如何布置源代码控制？你会在基地启动存储库吗？或者您会为每个工作簿解决方案创建一个存储库吗？你会重新安排文件夹吗？
现在我们已经完成了最初的开发，我们即将有一大批外部开发人员来帮助我们转换其余的工作簿，我真的很喜欢他们能够检查出来的想法从基本目录开始，并准备好所有依赖项。我还担心在一个源控制存储库下有20多个解决方案/项目会产生其他问题。
我希望所有人都能尽可能地加入项目，但我不想牺牲长期可用性。在我看来，我一直在来回，每个解决方案的一个存储库或一个存储库更简单？
我很欣赏你的洞察力，因为我很新鲜。
附加信息：目前，我个人使用Mercurial，但该项目可能会转移到StarTeam，除非我能为其他事情做出一些有说服力的论据。
答案 0 :(得分：1)
您在问题中未提及您正在使用的源控件。因为听起来您不需要限制外部开发人员访问存储库的其余部分，所以我不会为设置多个存储库而烦恼。我认为，除非您的代码遇到数百万行大小，否则存储库大小不是问题。
这完全取决于您的修订控制系统支持的功能。在subversion中，您可以将其他文件夹声明为外部文件，并为该文件夹的内容提供文件URL，这将导致subversion将该文件夹作为单独的存储库处理，即使它位于您的文件夹结构中。