处理多个subversion项目之间的关系

时间:2009-09-10 12:46:49

标签: c++ svn repository repository-design

在我的公司,我们使用一个SVN存储库来保存我们的C ++代码。代码库由公共部分(基础结构和应用程序)和客户端项目(作为插件开发)组成。

存储库布局如下所示:

  • 基础设施
  • App1的
  • App2的
  • App3的
  • 项目换客户端 - 1
    • App1的-插件
    • App2的-插件
    • 配置
  • 项目换客户-2-
    • App1的-插件
    • App2的-插件
    • 配置

客户项目的典型版本包括项目数据及其使用的每个项目(例如基础设施)。

每个目录的实际布局是 -

  • 基础设施
    • 分支
    • 标记
    • 躯干
  • 项目换客户-2-
    • 分支
    • 标记
    • 躯干

其他项目也是如此。

上面的布局有几个问题:

  1. 很难为客户项目启动一个全新的开发环境,因为必须检查所有涉及的项目(例如:Infrastructure,App1,App2,project-for-client-1)。
  2. 由于与上述相同的原因,很难在客户项目中标记版本。
  3. 如果客户项目需要更改一些公共代码(例如基础设施),我们有时会使用分支。很难跟踪项目中使用哪些分支。
  4. SVN有什么方法可以解决上述任何问题?我想过在客户端项目中使用svn:externals,但在阅读this post之后我明白这可能不是正确的选择。

5 个答案:

答案 0 :(得分:3)

您可以使用svn:externals处理此问题。这是svn repo中某个地方的网址 这使您可以拉入不同存储库(或同一个存储库)的部分内容。使用它的一种方法是在project-for-client2下,你将svn:externals链接添加到你需要的基础设施分支,你需要的app1的分支等等。所以当你检查project-for-client2时,你会得到所有正确的作品。

svn:externals链接与其他所有内容一起版本化,因此project-for-client1被标记,分支和更新,正确的外部分支将始终被拉入。

答案 1 :(得分:2)

是的,很糟糕。我们做同样的事情,但我真的不能想到更好的布局。

所以,我们所拥有的是一组脚本,可以自动化所有与subversion相关的内容。每个客户的项目都将包含一个名为project.list的文件,其中包含构建该客户所需的所有子版本项目/路径。例如:

Infrastructure/trunk
LibraryA/trunk
LibraryB/branches/foo
CustomerC/trunk

然后每个脚本看起来像这样:

for PROJ in $(cat project.list); do
    # execute commands here
done

命令可能是结帐,更新或标记。它比这复杂一点,但它确实意味着一切都是一致的,检查,更新和标记成为一个命令。

当然,我们尝试尽可能少地分支,这是我可能做出的最重要的建议。如果我们需要分支一些东西,我们将尝试使用trunk或者尽可能多的依赖项的先前标记版本。

答案 2 :(得分:2)

建议从

更改目录布局
  • 基础设施
    • 分支
    • 标记
    • 躯干
  • 项目换客户端 - 1
    • 分支
    • 标记
    • 躯干
  • 项目换客户-2-
    • 分支
    • 标记
    • 躯干

  • 分支
    • 特征-1
      • 基础设施
      • 项目换客户-1
      • 项目换客户-2
  • 标记
  • 躯干
    • 基础设施
    • 项目换客户-1
    • 项目换客户-2

此布局也存在一些问题。分支变得庞大,但至少在代码中标记特定位置更容易。

要使用代码,只需检查主干并使用它即可。然后,您不需要检查所有不同项目的脚本。他们只是用“../Inrastructure”来引用基础设施。此布局的另一个问题是,如果要完全独立地处理项目,则需要签出多个副本。否则,对一个项目进行基础结构更改可能会导致另一个项目在更新之前不进行编译。

这可能会使发布版本变得更加麻烦,并将代码分离出来用于不同的项目。

答案 3 :(得分:2)

首先,我不同意外部是邪恶的。虽然它们并不完美。

目前,您正在进行多次检查以构建工作副本。如果您使用外部设备,它将完成此操作,但每次都会自动且一致。

如果将外部指向目标项目中的标记(和/或特定修订),则只需标记每个版本的当前项目(因为该标记将准确指示您指向的外部)。您还可以在项目中记录更改外部参考的时间,以便使用新版本的特定库。

外部不是灵丹妙药 - 正如帖子所示,可能存在问题。我确信有比外部更好的东西,但我还没有找到(甚至在概念上)。当然,您正在使用的结构可以在您的开发过程中产生大量信息和控制,使用外部可以添加。然而,他遇到的问题不是根本腐败问题 - 干净的获取会解决所有问题,并且非常罕见(你真的无法在你的仓库中创建一个新的图书馆分支吗?)。

要考虑的要点 - 使用递归外部。我不会因为是或否而被出售,而是采取务实的态度。

考虑使用活塞,正如文章所暗示的那样,我没有看到它在行动中所以无法真正评论,它可能会以更好的方式完成与外部相同的工作。

答案 4 :(得分:0)

根据我的经验,我认为为每个项目建立一个存储库更有用。否则你会遇到问题,而且如果其他项目发生变化可能会引起混淆,修订号也会发生变化。

只有在各个项目之间存在关联时,例如软件,硬件原理图,文档等。我们使用单个存储库,因此修订版号用于使整个包装到已知状态。