代码之家 › 专栏 › 技术社区 › viraptor

使用自定义本地补丁管理软件

patch release-management deployment

1

viraptor · 技术社区 · 15 年前

我正试图找到一种在生产中部署带有定制补丁的软件的方法。基本软件是开放源码的,有自己的repos(svn),我们有一些补丁只能为一个服务而不是另一个服务选择(所以我们在一个服务器上有base+patcha+patchb,在另一个服务器上有base+patcha+patchc)。

一切都将部署为包,这非常简单。我想的问题是:我们如何存储修改?以下是我思考的一些方法:

我试过使用Quilt/Patch Series+在构建时从上游下载一个特定版本。这很好地工作,直到我们需要将补丁移植到新版本。因为Quilt需要一个树的副本来修改补丁,所以修复这些东西需要很长时间。另外,在不同的服务器上部署不同的版本意味着我们需要有不同的构建脚本。
我可以将存储库克隆到本地git/hg中,并通过本地修改创建一个分支。这对于向前移植补丁很好,我可以在我的分支上制作本地发布标签,但不幸的是,我丢失了关于单独补丁的信息。当然,我可以看到与上游的区别,但是我失去了对不同局部修改的清晰分离。
我尝试了堆叠的git/hg mq,但据我所见,它们并不容易导出补丁系列。它们有利于存储正在进行的工作。我可以使用bitback所做的相同技巧,在“存储库内部”创建补丁队列来导出它们,但是每个补丁队列将分别分配给一个分支(在每个使用 patchA 例如)。

你还有其他的想法、文章和标准化的方法吗?我提到的其他优点和缺点?

1 回复 | 直到 13 年前

1

0

RJHunter 13 年前

我知道你问了很久,但你的答案就在这里:

我可以将存储库克隆到本地git/hg并创建一个分支局部修改。这对移植补丁很好我可以在我的分支上做本地发布标签,但不幸的是我丢失有关单独补丁的信息。我可以看出当然是上游,但是我失去了不同地方的清晰分离修改。

通过Git的“提交”机制,您仍然可以清楚地分离不同的本地修改。

在我看来,Git“提交”与通过电子邮件发送的补丁基本上是相同的。也就是说,它用主题行和描述性正文文本来解释更改的原因来封装单个更改。当然,它还包含对所有相关文件的更改。

这个 git format-patch 指挥部(及其堂兄, git send-email )如果您确实需要将更改发送到外部系统(如上游系统),但信息仍然存在,那么将以这种格式实际输出。