使用自定义本地补丁管理软件
我正在尝试找到一种在生产中使用自定义补丁部署软件的方法。基础软件是开源的，有自己的存储库（SVN），我们有一些补丁可供选择，仅用于一项服务，而不是其他服务（因此我们在一台服务器上有base+patchA+patchB，在一台服务器上有base+patchA+patchC）其他）。
一切都将以包的形式部署，这非常简单。我正在考虑的问题是：我们如何存储修改？这些是我想到的一些方法：
- 我尝试使用 quilt / patch 系列+在构建时从上游下载特定版本。这很有效，直到我们需要将补丁移植到新版本为止。由于 quilt 需要树的副本来进行补丁修改，因此需要很长时间才能修复内容。此外，在不同的服务器上部署不同的版本意味着我们需要不同的构建脚本。
- 我可以将存储库克隆到本地 git/hg 并创建一个具有本地修改的分支。这对于向前移植补丁非常有用，我可以在我的分支上制作本地发布标签，但不幸的是我丢失了有关单独补丁的信息。当然，我可以看到与上游的差异，但我失去了不同本地修改的清晰分离。
- 我尝试了堆叠 git / hg-mq，但据我所知，它们并不容易导出补丁系列。它们非常适合存储正在进行的工作。我可以执行与 BitBucket 相同的技巧，并在“存储库内”创建补丁队列来导出它们，但随后每个补丁队列将分别分配给一个分支（每个使用 patchA 的本地分支都需要进行相同的修改）例如）。
您还有其他想法、文章、标准化方法吗？额外的优点和优点我提到的方法有缺点吗？
I'm trying to find a way to deploy software with custom patches in production. The base software is opensource with their own repos (SVN) and we've got some patches to select only for one service and not the other (so we've got base+patchA+patchB on one server and base+patchA+patchC on another).
Everything will be deployed as packages, which is pretty simple. The issue I'm thinking about is: how do we store the modifications? These are some ways I thought about:
- I've tried using quilt / patch series + downloading a specific revision from upstream when building. This works well, until we need to port patches to a new version. Since quilt needs a copy of the tree for patch modifications, it takes a really long time to fix stuff. Also, having different versions deployed on different servers means we need to have different build-scripts.
- I could clone the repository into local git/hg and create a branch with local modifications. That's great for porting patches forwards and I can make local release tags on my branch, but unfortunately I lose the information about separate patches. I can see the diff to upstream of course, but I lose the clear separation of different local modifications.
- I tried stacked git / hg-mq, but as far as I can see, they don't export the patch series easily. They're good for storing work in progress. I can do the same trick that BitBucket does and create patch queues "inside the repository" to export them, but then every patch queue would be assigned to a branch separately (same modification would be needed in every local branch that uses
patchAfor example).
Do you have any other ideas, articles, standardised ways of doing this? Additional pros & cons for the ways I mentioned?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我知道你问这个问题已经很久了，但你在这里得到了答案：
通过 Git 的“提交”机制，您仍然可以清楚地分离不同的本地修改。
在我看来，Git“提交”本质上与通过电子邮件发送的补丁是一样的。也就是说，它封装了单个更改，并带有主题行和解释更改原因的描述性正文文本。当然，它还包含所有相关文件的更改。
如果您确实需要将更改发送到外部系统（例如， ，上游），但信息仍然存在。
I know it's a long time since you asked, but you had the answer right here:
You still get the clear separation of different local modifications through Git's "commit" mechanism.
The way I see it, a Git "commit" is essentially the same thing as a patch sent by email. That is, it encapsulates a single change with a subject line and descriptive body text explaining the reason for the change. Of course, it also contains the changes to all the relevant files.
The
git format-patchcommand (and its cousin,git send-email) will actually output in this format if you do need to send the changes to an outside system (eg, upstream), but the information is there anyway.