应用错误收集

如果我们发现某些分支中的错误，我们会修复它（检查图片上的新版本）。但我们也很有兴趣将此修复程序移至旧版本和主要开发分支：

a-->b-->c              (Old release)
|    
A-->B-->C-->D           (Main release)
    |
    1-->2-->bugfix-->4  (New release)

svn 请记住svn：merge属性（来自svn 1.6,2009）哪个版本合并到哪个分支。因此，下次如果合并修订区域，则会先从合并修补程序中跳过合并修订。

如何处理现代DVCS？

我需要制作普通补丁并将其应用到每个分支机构，或者DVCS有一些帮助吗？

注意：我不能将 New 分支合并到 Main ，因为之前的更改集也会移动到 Main 分支

无法使用Rebase，因为很多开发人员都会发布新版本。

我很有兴趣回答命名的braches模式和多存储库模式。

PS。 Andy 建议找到对其有影响的所有分支的公共父级，更新它，对该错误应用修复并将修复移动到受影响的分支。< / p>

通过更新旧的变更集并进行更改，您可以创建新分支。我建议创建命名分支（将其命名为 bugID ），以便稍后您可以轻松返回它。

找到我们有兴趣修复bug的所有分支机构的共同父母都有问题。

第一个解决方案（暗示 Andy ）使用 $ hg / git / bzr blame 并仔细检查所有受影响文件的输出。这包括首先修复一些最新的变更集上的错误，然后才能找到责备哪个变更集引入了一个错误。然后，您需要 rebase 修复（补丁）到公共父变更集。

另一个解决方案是使用 $ hg / git / bzr bisect （您也可以手动执行更新以查找引入了错误的第一个修订版）。这可以是扩展但更多 true 解决方案，因为允许填充错误修复任何分支，其中存在错误。

我认为最好首先找到第一个BAD 变更集然后修复一个错误，而不是先修复一个错误，然后找到第一个BAD 变更集（除了你的情况除外）已经知道如何修复bug）。同时引入差异可以帮助理解它发生的原因。

PPS。对于错误，很明显哪个分支可以实现合并更改到任何受影响的分支。

如果询问如何从开发分支发布分支的后端功能，那么会出现有趣的问题。如您所见，您必须在发布分支之前的changeset开始提交功能更改集。但是当你开发功能时，你可能不知道你需要哪种后端功能。使用 svn：merge VCS，请记住所有后退。 DVCS怎么样？