Mercurial 分支与编译标志：一个代码库——多个产品

Posted 2023-02-24

【中文标题】Mercurial 分支与编译标志：一个代码库——多个产品

【英文标题】：Mercurial Branches vs. Compilation Flags: One Codebase -- Multiple Products

【发布时间】：2011-01-07 08:21:02

【问题描述】：

假设我正在创建一组产品，它们共享大部分代码但不是全部（例如：具有多个前端的应用程序：命令行、Windows/MAC/Linux GUI、移动（最小）GUI、 Web GUI 等）

此外，假设共享代码不能轻易拆分和“库化”。

我正在考虑为不同的产品使用 mercurial 命名分支（例如分支：CLI、Windows、MAC、Linux、Mobile、Web）或代码中的编译标志（例如#if (FRONT_END == CLI) #elif (FRONT_END == WEB) ...）。

我对这两种方法都不满意。以下是我的不满：

命名分支：

如果我更改了一段共享代码，我需要将它与所有分支合并。 是否有 hg 命令可以（半）自动执行此操作？ 很难/快速查看特定功能如何在所有分支中实现（可视化代码某个区域的差异）

编译标志：

代码混乱 没有隐式的分支修订历史。必须手动执行（提交时会显示哪些产品受到影响）

你能建议吗：

如何减轻我的疑虑？ 不同的观点 结合这两种方法的优雅方式

感谢

【问题讨论】：

您是否从同一个项目构建不同的前端？为什么这会对共享代码产生影响？ IE。为什么共享代码需要知道它需要在 Web 应用程序和桌面应用程序中使用？

共享代码拆分有什么问题？

【参考方案1】：

我想，我有适合你的最佳策略。

前言：我非常、非常讨厌 ifdef'ed spaghetti-code

---

命名的分支机构还不错，但有管理层的缺点，是的。经过一些尝试和失败后，我停止了“单一代码库 + 多 MQ 补丁”的想法。使用新鲜的 Mercurial，您甚至可以拥有多个队列，您可以使用受保护的补丁......因此您有一个 vanilla 代码 - 许多（任何）目标

未来阅读：《Mercurial：权威指南》，Chapter 12. Managing change with Mercurial Queues 和 Chapter 13. Advanced uses of Mercurial Queues