源控制布局

Question

我开发了各种应用程序，并有3-4个杂项库，我在这些应用程序中重复使用（一个用于数学，一个用于数据库功能等）。

目前我有一个主源目录，每个项目都作为顶级目录（包括我的帮助项目）。每个需要帮助的项目都会将整个项目添加为解决方案中的参考（而不是针对库）。这允许快速调试/更新帮助程序库，但很快就会变得很麻烦，因为我总是需要重建帮助程序，并且可以对许多旧程序使用的接口进行重大更改。

所有这些都存储在subversion存储库的trunk目录中，当我分支特定目录时，我创建了一个大型分支等。这很难保持向后兼容性以及剪切代码大小和本地大小存储库。

处理这些情况的最佳方法是什么？你如何布置各种项目。

您是否将每个项目都放在自己的subversion存储库中？或者你使用一个存储库，其中包含多个顶级项目和主干/分支/标签？

您如何参考替代项目？你只是编译这些并引用数据吗？

Answer 1

请在Projects folder structure recommendation和How do you organize your version control repository?上查看我的回答。

对于您的具体问题，问题是管理项目间的依赖关系。答案是对它们进行版本化 - 依赖于另一个项目的每个项目应该仅依赖于来自该项目的二进制可交付项（或者如果不是已编译的程序/库则最接近的等价项），并且该可交付项应该在每个这样的引用中进行版本化。当然，您首先需要确保每个项目产生一个且仅一个二元可交付成果（或等效物）。

通过仅依赖于来自另一个项目的二进制可交付成果，您可以使每个项目独立并大大简化其维护，因为其“构建接口”是单个文件。进入另一个项目的源/构建就像进入库的实现中间=很多问题。

通过对每个项目进行版本控制，您可以代表另一个（新）项目修改特定项目的源，但不会影响使用它的任何其他旧项目。实际上，每个项目都成为一个产品。与任何产品一样，您应该管理其版本及其与其他产品的兼容性。

Answer 2

我的可重用库是在单独的项目中开发的，在存储库中有单独的源代码目录（我使用TFS，但它应该适用于SVN）。我在一个公共位置发布这些库的版本 - 在我的例子中是通过DFS引用的网络共享。我根据需要将已发布库的引用添加到我的其他项目中。有时我会使用版本控制（命名版本），如果我发现由于某种原因我需要维护库的多个版本。从某种意义上说，我将它们视为第三方组件，不直接引用它们的项目。

Answer 3

我认为您需要一个针对常见项目的单独解决方案，并为它们创建自己的构建过程。我会将它们作为主项目中的二进制引用链接起来。如果你有pdb文件，你仍然可以使用visual studio调试这段代码。我认为这是扩展或解决这些问题的唯一方法

考虑一下，将所有共享库放在一个位置，让本地项目创建一个ext目录来放置所有共享链接二进制文件。然后，您可以编写脚本来检查更新版本等，以避免不得不手动升级

Answer 4

我从未使用过subversion，但我可以在存储库问题之外提供一些信息。我的答案是它真的取决于scenairo和公司。对于我参与的最大项目之一，我们使用了以下结构。该项目由大约20个核心组件组成，这些组件将在各种应用程序之间共享。我们也在使用TFS。

我们定义了一个Common TFS项目，该项目包含一个主构建解决方案，用于构建公共项目中的所有项目。当我们构建时，我们将发布二进制文件。

然后我们为每个业务部门及其各种应用程序（每个BU可以有1到n个项目/应用程序）进行TFS项目。然后，我们设置应用程序，使用文件引用将二进制文件拉入自己的项目中。在这种情况下，业务部门将公共图书馆视为第三方产品。

在不太正式的情况下，我们会让业务单位直接引用构建输出（它们将被检入源控制系统）。这允许业务部门在编译后获得新版本，但正如您所指出的那样引入了兼容性问题。这是让他们完全孤立的帮助。