.net 源代码管理布局

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

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

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

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

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

---

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

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

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

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

---

在不太正式的情况下，我们会让业务部门直接引用构建输出（它们会被检查回源代码控制系统）。这允许业务部门在编译新版本后获得新版本，但正如您所指出的，这会带来兼容性问题。这就是让它们完全隔离有帮助的地方。

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

我认为，对于常见的项目，您需要一个单独的解决方案，并有自己的构建过程。我会将它们作为二进制引用链接到您的主要项目中。如果您有pdb文件，仍然可以使用visual studio对此代码进行调试。我认为这是扩大规模的唯一途径，否则你会一直面临这些问题

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

请参阅和上的我的答案

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

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

---

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

不要将生成的任何内容放入源代码管理系统：它不是源代码。对输出二进制文件进行版本控制是很好的，所以不要用直接的未版本依赖关系（这会像您所说的那样引入兼容性问题）来破坏它。半步只会增加成本，但不会带来好处。将它们放入源代码中可以让我们控制源代码管理树，并使我们能够轻松地进行文件引用，而无需指定二进制文件的放置位置。我同意在大多数情况下，你不应该把生成的输出，但在这种情况下，可以有一个好处