SVN 相关，与“主干/分支”概念有关答案

【问题标题】：SVN related, in relation to the "trunk / branches" conceptSVN 相关，与“主干/分支”概念有关
【发布时间】：2012-04-12 17:39:20
【问题描述】：

我已经用 SVN 试验了一段时间。我有一个小测试项目来测试作为 SVN 管理员和 SVN 用户的不同方面。这里先做一点介绍。

我有一个脚本：

<repos>/python/testScript/trunk/testScript.py

此脚本检查环境变量 $LOCALSITE 并列出结果。今天我发现了一个错误，如果那个环境会破坏脚本。变量未设置。所以我立即分支到：

<repos>/python/testScript/branches/branch-00.01.xx/testScript.py

还推送了一个标签：

<repos>/python/testScript/tags/0.1.1/testScript.py

所以这个第一个标签仍然继承了“如果 $LOCALSITE 未设置则失败”的错误。就像树干仍然存在同样的问题。

我推送标签的原因是我 %100 确定该脚本将在正确设置 $LOCALSITE 的环境中执行。所以它不会破裂。人们可以像往常一样继续使用“tag-0.1.1”。

但是我仍然想解决这个问题。那么问题来了：

我已经在“branch-00.01.xx/testScript.py”上修复并测试了这个问题，所以现在我知道“branch-00.01.xx”正在工作，除非还有更多隐藏的错误。那是正确的步骤吗？还是我应该修好后备箱？

现在我该怎么办？我应该将固定分支推送到新标签吗？还是我应该修复主干并杀死分支“branch-00.01.xx”？

谢谢。

【问题讨论】：

标签： python svn testing software-design

【解决方案1】：

分支模型假设当你完成一个特性的工作时，你会将它合并回主干。无需标记它，因为您不想将其暴露给外界。（实际上，您可以直接在主干上完成此修复，但我知道您正在探索这个过程）。

既然你刚刚开始，我建议你看看 mercurial：它的语法很像 svn，但它是下一代“分布式”版本控制。我不是说 svn 垃圾，它是一个很棒的系统，但这也是你想知道的。

【讨论】：

是的，我后来想了想，看来我应该这样做：修好后备箱。谢谢。是的，我正在尝试模拟 svn 体验。
分支也适用于错误修复（或新功能），如果在错误修复完成之前主干可能会发生变化。当我自己工作时，我只将它们用于重大实验，因为我可能会在实验完成之前对主干进行小幅修复。还要隔离实验以防万一它失败，我最终把它放在一边（但可能想稍后回来并从中挑选）。

【解决方案2】：

在某种程度上，您选择什么并不重要，因为主干/分支只是方便起见的逻辑概念（名称），没有技术差异。

根据我的经验，您通常会想到主干，您在其中进行最新和最伟大的开发，而将分支留给您已经推送给客户并且可能需要稍后继续工作的版本，但不想担心正在进行的主干改变破坏事物。

【讨论】：

【解决方案3】：

不同的网站以不同的方式处理此问题。很多都是政策问题。

我见过的最好的方式，IMO：

1) Trunk 相对来说是免费的，但可能有一个政策，即在没有首先运行自动化测试的情况下，任何东西都不能被检入到 Trunk 中。这往往会减少在主干上等待的人能够很好地工作以测试不相关的更改。

2) 分支仍在变化，但变化会逐渐变慢。可以评估签入主干的事物以签入相关分支。一段时间后，一个分支可能会被“冻结”，例如通过设置一个提交钩子来拒绝所有在签入中不包含某些魔术 cookie 的提交。如果有人非常想要（通过查看提交历史），这很容易解决，但它消除了对冻结分支的意外签入。

3) 当一个给定的分支看起来相当稳定时，它会在打包用于 Q/A 之前被复制到一个标签中。这些标签一旦创建就永远不会改变，作为一个参考点——尽管理论上 SVN 将它们视为同样可变的——差异再次是一个政策问题。

这一切中令人讨厌的部分是 SVN 外部引用。如果你没有，分支和标记很容易 - 只需 svn copy 就完成了。如果你有它们，你最终会编写一个脚本来调整外部引用，作为分支/标记过程的一部分。但有时外部参考确实很有用。我一直在尝试在分支期间“内部化”所有外部引用 - IOW 将所有外部引用复制为新创建的分支的一部分，以保持分支和标记简单。然后，当有重要修复时，开发人员需要检查更多地方，但到目前为止，至少在我的个人项目中，这似乎是帮助而不是障碍。

【讨论】：