源代码管理布局

Question

我开发了各种各样的应用程序，并且有3-4个杂乱库，我在这些应用程序中重用它们(一个用于数学，一个用于数据库函数等)。

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

所有这些都存储在subversion存储库的主干目录中，当我分支特定的目录时，我会创建大量的分支，等等。这很难维护向后兼容性以及存储库的剪切代码大小和本地大小。

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

您是否将每个项目放在其自己的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目录来放置所有共享链接的二进制文件。然后，您可以编写脚本来检查更新的版本等，以避免手动升级