4

我正在重新构建我们现有的代码库。我们正在迁移到 SVN 并期望软件活动增加，我需要一个可扩展且健壮的结构。

我希望我们的要求与其他公司的要求不会太不同，所以我会从你们那里得到一些反馈。

问题

我有许多项目：库和应用程序。应用程序依赖于库，并且一些库相互依赖。

我们有许多产品。每个产品都是一个 MSI，其中包含一些库和一些应用程序。

这些项目是 C++，它们之间的依赖关系是头文件和导入库/DLL——我们目前正在 Windows 下开发，但最终将移植到 MACOS 和 Linux。

尽管对于其中一些项目来说，每个项目都是一个独立的实体，但我们最终会同时更新其中的几个项目。例如，在处理 app_0 时，我们可能会更改 lib_a 中的一些代码（可能是错误修复、添加的功能等）。但我们不想强迫开发人员必须始终检查项目依赖项的源代码。

潜在的解决方案

每个项目都在 SVN 中自己的目录中，并且有一个“dependencies.txt”文件，其中列出了它需要的头文件、.libs 和 .dll 以及应该在磁盘上创建的位置。签出项目后，脚本会自动解析此文件以检索依赖项。头文件是从 SVN（部分检出）中检索的，而二进制文件是从服务器获取的。

项目遵循通常的主干/标签/分支结构。

在磁盘上，每个项目都存在于自己的目录中，采用扁平结构。输出目录包含二进制文件，这些二进制文件要么通过构建项目生成，要么作为处理“dependencies.txt”文件的结果从服务器复制。

  • 输出
    • win32_debug
      • lib_a.lib
      • lib_a.dll
  • lib_a
    • 来源
    • 上市
      • lib_a.h
      • 其他.h
  • 项目_1
    • 依赖项.txt
    • 建造
    • 来源
      • 项目_1.cpp

这种结构意味着我们可以在 project_1 上工作，而无需检查 lib_a 的源代码。但是我们仍然可以将库签入“./lib_a”并使用其源代码而不需要对 project_1 进行任何修改，因为头文件和导入库的位置保持不变。

“安装程序”项目用于发布软件。该项目将检查发布所需的所有项目并构建它们。

在发布期间，会为所有项目创建一个“发布”分支。应该进入发布的所有更改都提交给它。这样，我们只需要在结帐（跟踪发布分支）上运行更新即可获得最新的更改。

4

1 回答 1

3

有几种处理依赖问题的方法：

  • 使用发布存储库并将您的库和头文件视为已发布的软件。您可以使用wget提取正确版本的库和头文件。优点是您不会将大块的二进制代码签入您的 Subversion 存储库。Subversion 确实处理二进制文件，但它们在您的存储库中占用了大量空间。

  • 您可以使用该svn:externals物业。这允许您在另一个目录中自动包含另一个存储库目录。但是，要非常非常小心！

想象一下，您有以下内容：

trunk/project_A
trunk/project_B
trunk/subproject

您想包含trunk/subproject在 中project_A，并在 上设置以下属性project_A：

$ svn propset svn:externals "/trunk/subproject subproject" .

当您分支 project_A 时，您的子项目仍将位于主干上。不是你想要的。如果您标记project_A，该标记将不是快照，因为subproject它仍指向主干。有几种方法可以处理这个问题：

  • 使用相对目录。即，svn propset "svn:externals ../subproject" subproject .。这将确保当您分支时project_A，它将查看您的子项目的分支而不是主干。当你标记project_A. 该标签将指向子项目的相同标签。问题是您必须使用 project_A 分支和标记您的子项目。

  • 使用特定版本。您可以使用该-r参数将特定版本的子项目修复为 project_A，或者您可以简单地使用标签。无论哪种方式，您都及时冻结了子项目。Word o' 警告：如果有人签出 project_A，他们可以修改子项目，即使它位于标签目录中。您将需要某种预提交钩子来防止某人更改标签。

于 2013-05-07T13:07:23.107 回答