通过补丁或合并建议提交启动板上的错误修复?

更新: 看起来Openerp项目的官方文档现在已经 guidelines for making merge proposals . 我也会把我的版本留在这里,因为它有一些不同的细节。

在和Bazaar和LaunchPad玩了几天之后,提交了一些补丁和合并建议,我想我会写一份我发现的总结。LaunchPad和Bazaar提供了一些强大的工具,特别是对于社区驱动的项目,但我认为新用户不太可能 fall into the pit of success 然而。有几种方法可以使这个过程缓慢而令人沮丧,所以我希望这次演练能够帮助一些人避免一些错误。

这是我学习的工作流程,用于修复bug,并将合并建议提交回团队,用于在LaunchPad上托管的项目。我在一个GNU/Linux工作站上工作,但我认为bazaar命令在其他平台上是等效的。在本例中,我正在处理OpenObject项目组中名为OpenObject插件的项目之一。维护者的用户名是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 .

下一步是从官方分支中签出源代码。它通常被称为主干,但您可能更喜欢使用一个稳定的发布分支,该分支只用于修复bug。在这个例子中,我将处理5.0版本分支。

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

对于大型项目来说,这一步可能是整个过程中最慢的一步,因为您要将所有代码以及整个项目的所有历史记录复制到硬盘上。注意,我在将要处理的特性之后命名分支。

创建分支

此时,您可以尝试在本地工作站上构建和运行代码。您可以对代码进行更改,但是您还没有任何地方提交它们,因为可能不允许您直接提交到官方分支。要发布代码更改,需要创建公共分支。如果你刚接触LaunchPad,你需要 create an account and register a public key 第一。

一旦你建立了你的帐户,你就可以将你自己的分支作为官方分支的副本发布,并开始使用它。这个 lp-login 命令告诉Bazaar在LaunchPad站点上使用的帐户名,以及 whoami 命令告诉Bazaar在提交的每个修订中使用什么名称。您在中使用的电子邮件地址 呼玛 应与为启动板帐户配置的电子邮件地址之一匹配。

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

您切换到新的分支,这样提交将记录在本地历史记录和公共分支中。你可能想了解 the difference between a checkout and a branch . 把它做成一个堆叠的分支意味着创建它非常快,因为它只包含了不在官方分支中的历史。 This blog post 听起来像是公共项目的分支机构应该默认为堆叠,但这对我来说不起作用。请注意,我根据要添加的一些特性命名了分支。AS bialix suggested ,我为每个特性创建了一个单独的分支,我最终将建议合并回正式分支。

提交并提出合并建议

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

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

您可以从分支结构中的任何位置提交,默认情况下,它提交整个分支。跑 bzr help commit 详情。你也可能会发现 bzr status 和 bzr diff 很有用。

一旦您对这些更改感到满意,并且已将所有内容提交到您的功能分支,您就可以转到LaunchPad网站并创建合并建议。下面是一个方便的快捷方式,您可以运行它来启动分支机构的网页:

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

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

有一个 e-mail interface 在整个过程中引导您的建议,或者您可以只使用网站。

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

正在进行的变化

如果您在几个功能上工作,而维护人员在审查您的建议时速度不是很快,那么您可能需要建立自己的主线分支。这个分支将您的所有特性收集在一起,并保存您将在服务器上运行的代码。如果官方分支不太稳定,并且您希望为生产环境稳定分支,那么它也很有用。然后,您可以决定何时升级到最新版本,以及何时为伤害您的用户的错误采取特定的补丁。

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

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

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

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

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

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