我开发了各种应用程序，并且在这些应用程序中重复使用了3-4个杂项库（一个用于数学，一个用于数据库功能等）。源代码管理布局
目前我有一个主源代码目录，每个项目都作为顶级目录（包括我的帮助程序项目）。并且每个需要助手的项目都将整个项目添加为解决方案中的参考（而不是针对库）。这允许对助手库进行快速调试/更新，但是很快就会变得麻烦，因为我总是需要重新构建帮助程序，并且可以对较早的程序使用的接口进行重大更改。
所有这些都存储在Subversion存储库的trunk目录中，当我分支特定的目录时，我创建了一个大规模的分支等。这很难保持向后兼容性以及剪切代码大小和本地大小的存储库。
处理这些情况的最佳方法是什么？你如何布置你的各种项目。
您是否将每个项目放置在自己的Subversion存储库中？或者，您是否使用一个具有多个顶级项目和其下的trunk/branch /标签的存储库？
你如何参考替代项目？你只是编译这些和参考数据？
请参阅我在Projects folder structure recommendation和How do you organize your version control repository?答案不必浪费时间。
为了您的具体问题，这个问题是管理项目间的依赖关系。答案是他们的版本 - 每一个依赖于另一个项目应该只依赖于从该项目（或最接近的等效如果没有编译的程序/库）的二进制交付，并且交付应在每个这样的参考版本。当然，您首先需要确保每个项目都生成一个和一个二进制可交付成果（或等价物）。
通过仅在从另一个项目二进制交付依赖，你使每个项目独立，大大缓解了维护，因为其“打造界面”是一个单一的文件。到达另一个项目的源代码/构建就像进入图书馆实施的中间阶段=很多问题。
通过版本控制每一个项目，你可以修改代表另一个（新的）项目的特定项目的来源，但并不影响任何使用它的其他老项目。实际上，每个项目都会成为PRODUCT。像任何产品一样，您应该管理其版本以及与其他产品的兼容性。
我从来没有使用过颠覆，但我可以在存储库问题之外提供一些信息。我的答案是真的取决于scenairo和公司。对于我参与的最大项目之一，我们使用了以下结构。该项目由大约20个核心组件组成，这些核心组件将在各种应用程序中共享。我们也在使用TFS。
我们定义了一个通用TFS项目，其中包含一个主构建解决方案来构建公共项目中的所有项目。当我们建立时，我们会发布二进制文件。
然后，我们为每个业务部门及其各种应用程序（每个BU可以有1到n个项目/应用程序）提供TFS项目。然后，我们设置应用程序以使用文件引用将二进制文件拖放到他们自己的项目中。在这种情况下，业务部门将公共图书馆视为第三方产品。
在不太正式的情况下，我们会让业务单元直接引用构建输出（他们会被检查回到源代码管理系统中）。这允许业务部门在编译完成后获得新版本，但正如您所指出的那样引入了兼容性问题。这是让他们完全孤立帮助的地方。
我的可重复使用的库是在单独的项目中开发的，在源代码库中有单独的源代码目录（我使用TFS，但它应该适用于SVN）。我在一个公共位置发布这些库的版本 - 在我的情况下，通过DFS引用网络共享。根据需要，将已发布库的引用添加到我的其他项目中。有时我会使用版本控制（命名版本），如果我发现由于某种原因需要维护多个版本的库。从某种意义上说，我将它们全部视为第三方组件，不要直接引用它们的项目。
我认为你需要一个共同的项目seperete解决方案，并有他们自己的构建过程。我会将它们作为主项目中的二进制引用链接起来。如果您有pdb文件，您仍然可以通过使用visual studio来调试此代码。我觉得这个规模的唯一途径，或者你有保留这些问题
一想思考的是把所有的共享库在一个位置，并有当地项目创建一个ext目录把所有的共享链接的二进制文件。然后，您可以编写脚本来检查是否有更新版本等，以避免手动升级
不要把所生成到源控制系统，任何东西：它不是源。对输出二进制文件进行版本控制是很好的，所以不要用直接的未版本化依赖关系（它引入了像你说的那样的兼容性问题）来妥协。半步只会增加成本，但不会授予收益。 – 2008-12-01 03:19:14