我开发了各种应用程序并拥有 3-4 个杂项库，我在这些应用程序中重复使用它们（一个用于数学，一个用于数据库函数等）。
目前我有一个主源目录，每个项目都作为顶级目录（包括我的辅助项目）。并且每个需要帮助器的项目都将整个项目添加为解决方案中的参考（而不是针对库）。这样可以快速调试/更新帮助程序库，但很快就会变得很麻烦，因为我总是必须重新构建帮助程序，并且可以对许多旧程序使用的接口进行重大更改。
所有这些都存储在 subversion 存储库的主干目录中，当我分支特定目录时，我会创建一个巨大的分支等。这很难保持向后兼容性以及剪切代码大小和本地大小存储库。
处理这些情况的最佳方法是什么？您如何安排各种项目。
您是否将每个项目都放在自己的 subversion 存储库中？或者您是否使用一个包含多个顶级项目和主干/分支/标签的存储库？
您如何参考替代项目？你只是编译这些并引用数据吗？
【问题讨论】：
标签： .net version-control file
请在Projects folder structure recommendation和How do you organize your version control repository?查看我的回答。
对于您的具体问题，问题在于管理项目间的依赖关系。答案是对它们进行版本控制——每个依赖于另一个项目的项目应该只依赖于该项目的二进制可交付成果（或最接近的等价物，如果不是已编译的程序/库），并且该可交付成果应该在每个此类引用中进行版本控制。当然，您首先需要确保每个项目都生成一个且仅一个二进制可交付成果（或同等成果）。
通过仅依赖另一个项目的二进制可交付成果，您可以使每个项目独立并大大简化其维护，因为它的“构建接口”是一个文件。进入另一个项目的源代码/构建就像进入一个库的实现中间 = 很多问题。
通过对每个项目进行版本控制，您可以代表另一个（新）项目修改特定项目的源代码，但不会影响使用它的任何其他旧项目。实际上，每个项目都成为产品。与任何产品一样，您应该管理其版本及其与其他产品的兼容性。
【讨论】：
我的可重用库是在存储库中具有单独源代码目录的单独项目中开发的（我使用 TFS，但它应该适用于 SVN）。我在一个公共位置发布这些库的版本——在我的例子中是通过 DFS 引用的网络共享。我根据需要将对已发布库的引用添加到我的其他项目中。如果我发现出于某种原因需要维护一个库的多个版本，有时我会使用版本控制（命名版本）。从某种意义上说，我将它们都视为 3rd-party 组件，不直接引用他们的项目。
【讨论】：
我认为您需要为常见项目提供一个单独的解决方案，并为它们提供自己的构建过程。我会将它们作为二进制引用链接到您的主要项目中。如果您有 pdb 文件，您仍然可以使用 Visual Studio 调试此代码。我认为这是扩展的唯一方法，否则您会一直遇到这些问题
可以考虑将所有共享库放在一个位置，并让本地项目创建一个 ext 目录来放置所有共享链接二进制文件。然后，您可以编写脚本来检查更新版本等，以避免不得不手动升级
【讨论】：
我从未使用过颠覆，但我可以在存储库问题之外提供一些信息。我的回答是这真的取决于场景和公司。对于我参与的最大项目之一，我们使用了以下结构。该项目由大约 20 个核心组件组成，这些组件将在各种应用程序之间共享。我们也在使用 TFS。
我们定义了一个通用 TFS 项目，其中包含一个主构建解决方案，用于构建通用项目中的所有项目。当我们构建时，我们会发布二进制文件。
然后，我们为每个业务部门及其各种应用程序创建了一个 TFS 项目（每个 BU 可以有 1 到 n 个项目/应用程序）。然后，我们设置应用程序以使用文件引用将二进制文件拉入他们自己的项目中。在这种情况下，业务部门将公共库视为第三方产品。
在不太正式的情况下，我们会让业务部门直接引用构建输出（它们会被检查回源代码控制系统）。这允许业务部门在编译后获得新版本，但正如您所指出的那样引入了兼容性问题。这就是让它们完全隔离的地方。
【讨论】：