9

我是LaunchpadBazaar的新手,我正在尝试找出提交错误修复的最佳方法。我正在使用一些托管在 Launchpad 上的相当流行的开源软件,但它不是很稳定。我已经创建了自己的项目分支来稳定它并仅应用我们需要的错误修复,而无需添加正在进行的开发中的其他更改。

当我提交错误然后想办法自己修复它们时,我会将修复推送到我们的稳定分支。我应该如何将修复发布回主项目?我可以创建一个补丁文件并将其附加到错误中,或者我可以为我们的稳定分支提议合并。

如果我修复了多个错误,我可以为每个错误制定单独的合并提案,还是它们是累积的?

4

2 回答 2

12

更新:看起来 OpenERP 项目的官方文档现在有关于提出合并建议的指南。我也会把我的版本留在这里,因为它有一些不同的细节。

在玩了几天 Bazaar 和 Launchpad 并提交了一些补丁和合并建议之后,我想我应该写一个我发现的摘要。Launchpad 和 Bazaar 提供了一些强大的工具,特别是对于社区驱动的项目,但我认为新用户还不太可能落入成功的陷阱。有几种方法可以让这个过程变得缓慢和令人沮丧,所以我希望这个演练可以帮助一些人避免一些错误。

这是我为在 Launchpad 上托管的项目进行错误修复并将合并提案提交回团队所学到的工作流程。我正在使用 GNU/Linux 工作站,但我认为 Bazaar 命令在其他平台上是等效的。在此示例中,我正在处理 OpenObject 项目组中的一个项目,称为 OpenObject Addons。维护者的用户名是 openerp。我将把我的工作区放在~/workspace文件夹中。

如果您想在此处了解有关任何命令的更多信息,请使用bzr help加号命令名称。

创建共享存储库

因为我要为我想要回馈给项目的每个特性创建一个分支,所以我不希望每个分支都拥有项目整个历史记录的单独副本。为避免这种情况,我创建了一个共享存储库,然后在其中创建每个分支。需要注意的一件事是,您的存储库格式必须与官方分支的格式相匹配,才能使后面的一些步骤正常工作。

检查官方分支上的存储库格式:

bzr info http://bazaar.launchpad.net/~openerp/openobject-addons/5.0

获取代码

现在创建一个工作区文件夹,该文件夹将保存您机器上的任何本地分支 - 我只是在项目之后命名它。然后使用您在官方分支上找到的格式在其中创建一个共享存储库。

cd ~
mkdir workspace
cd workspace
mkdir openobject-addons
cd openobject-addons
bzr init-repo --format=rich-root-pack .

下一步是查看官方分支的源代码。它通常称为主干,但您可能更喜欢使用仅用于修复错误的稳定版本分支。在这个例子中,我将在 5.0 发布分支上工作。

cd ~/workspace/openobject-addons
bzr checkout lp:~openerp/openobject-addons/5.0/ feature-x

这一步可能是大型项目整个过程中最慢的一步,因为您将整个项目的所有代码和所有历史记录复制到硬盘上。请注意,我以我将要处理的功能命名分支。

创建一个分支

此时,您可以尝试在本地工作站上构建和运行代码。您可以更改代码,但您还没有任何地方可以提交它们,因为您可能不允许直接提交到官方分支。要发布您的代码更改,您需要创建一个公共分支。如果您是 Launchpad 的新手,您需要先创建一个帐户并注册一个公钥

设置帐户后,您可以将自己的分支发布为官方分支的副本,然后开始使用它。该lp-login命令告诉 bazaar 在启动板站点上使用什么帐户名称,该whoami命令告诉 bazaar 在您提交的每个修订版上使用什么名称。您使用的电子邮件地址whoami应与您为 Launchpad 帐户配置的电子邮件地址之一匹配。

cd ~/workspace/openobject-addons/feature-x
bzr lp-login donkirkby
bzr whoami "Don Kirkby <donkirkby@example.com>"
bzr branch --stacked --switch lp:~openerp/openobject-addons/5.0/ lp:~donkirkby/openobject-addons/feature-x

您切换到新分支,以便将提交记录在您的本地历史记录和公共分支中。您可能想了解checkout 和 branch 之间的区别。将其设为堆叠分支意味着创建速度非常快,因为它只包含不在官方分支中的历史记录。这篇博客文章听起来像是公共项目的分支应该默认为堆叠,但这对我不起作用。请注意,我以我想添加的一些功能命名了分支。正如bialix 建议的那样,我为每个功能创建一个单独的分支,我最终会建议将其合并回官方分支。

提交并提出合并提案

现在您有了一个分支,您可以进行代码更改并提交它们。

cd ~/workspace/openobject-addons/feature-x
bzr commit -m "Fixed bug lp:12345 by fleaking the woverbinate() function."

您可以从分支结构中的任何位置提交,默认情况下它会提交整个分支。运行bzr help commit了解详情。您可能还会发现bzr statusbzr diff有用。

一旦您对更改感到满意并且您已将所有内容提交给您的功能分支,您就可以访问 Launchpad 网站并创建一个合并提案。这是一个方便的快捷方式,您可以运行它来启动分支的网页:

cd ~/workspace/openobject-addons/feature-x
bzr lp-open

创建合并提案后,Launchpad 将为它生成一个差异。非常值得回顾一下这个差异。有时我选择了错误的分支作为目标,我只注意到差异的变化比我预期的要多。还有一个bzr send合并提案的命令,但我没有使用它。

有一个电子邮件界面可以在整个过程中引导您的提案,或者您可以只使用该网站。

将分支附加到错误上也很有用,这样其他人就可以像在自己的系统上使用补丁一样使用它。

持续变化

如果您处理多个功能,并且维护人员在审查您的提案时不是很快,那么可能值得建立自己的主线分支。该分支将您的所有功能收集在一起,并保存您将在服务器上运行的代码。如果官方分支不是很稳定并且您想为您的生产环境稳定一个分支,它也很有用。然后,您可以决定何时升级到最新版本,以及何时为伤害用户的错误使用特定补丁。

第一步是创建另一个堆叠在官方分支上的分支:

cd ~/workspace/openobject-addons
bzr checkout lp:~openerp/openobject-addons/5.0/ main
cd main
bzr branch --stacked --switch lp:~openerp/openobject-addons/5.0/ lp:~donkirkby/openobject-addons/main

现在有两个您需要合并的更改来源。首先,从功能或错误修复分支合并:

cd ~/workspace/openobject-addons/main
bzr merge lp:~donkirkby/openobject-addons/feature-x/
bzr commit -m "Merged feature x"

当然,如果你还有特性分支的本地副本,做本地合并会更快:

cd ~/workspace/openobject-addons/main
bzr merge ../feature-x
bzr commit -m "Merged feature x"

其次,你偶尔会想要合并来自官方分支的最新最好的:

cd ~/workspace/openobject-addons/main
bzr merge --remember lp:~openerp/openobject-addons/5.0/
bzr commit -m "Merged from 5.0 branch"

从官方分支合并时使用后--remember,可以单独使用bzr merge从官方分支合并。如果项目使用标签来标记发布点,您可以查看标签列表并从标签合并。

cd ~/workspace/openobject-addons/main
bzr tags -d lp:~openerp/openobject-addons/5.0/
bzr merge -r tag:5.0.7rc2
于 2010-01-28T22:49:48.303 回答
1

此类策略(使用合并提案或补丁)应由项目本身的核心开发人员或维护人员定义。但作为一般规则,为每个修复使用单独的分支比普通补丁更可取。

  • 因为当主干分支开发向前推进时,普通补丁可能会过时。当您保留分支进行修复时,您可以根据主干中的最新更改更新您的修复。
  • 分支中的修复更易于分析,因为其他开发人员可以看到您修复问题的所有中间步骤,或者随着主干的更改,您的修复如何随着时间的推移而演变。
  • 此外,附在错误报告中的补丁也经常被遗漏或遗忘。虽然所有活动合并提案的列表都突出显示在每个项目的“分支”页面上。
  • 从您的分支合并您的修复意味着历史记录(和注释)将保留您的名字作为路径作者,而不是应用您的补丁的核心开发人员。

将所有修复程序保留在一个分支中不利于在合并提案中使用它。但它本身对于测试所有修复或将其用作稳定分支(例如用于 dogfooding)很有用。因此,我建议为每个单独的修复使用单独的(功能)分支,为它们归档单独的合并提案,然后像今天一样将这些分支合并到您的稳定分支中。这样,您可以完全自由地对每个修复应用额外的更改,然后将其再次合并到您的稳定分支。

如果您需要将现有的稳定分支拆分为几个单独的分支,您可以使用 John Meinel 在他的博客中描述的配方:http: //jam-bazaar.blogspot.com/2009/10/refactoring-work-for-review-和-keep.html

于 2010-01-23T12:54:05.903 回答