Mercurial 分支与编译标志：一个代码库 - 多个产品
假设我正在创建一组共享大部分代码但不是全部代码的产品（例如：具有多个前端的应用程序：命令行、Windows/MAC/Linux GUI、移动（最小）GUI、Web GUI 等。）
此外，可以说共享代码不能轻易地拆分和“库化”。
我正在考虑对不同的产品使用 Mercurial 命名分支（例如分支：CLI、Windows、MAC、Linux、Mobile、Web）或代码中的编译标志（例如 #if (FRONT_END == CLI) #elif (FRONT_END ==网络）...）。
我对这两种方法都不满意。这是我的不满：
命名分支：
- 如果我更改一段共享代码，我需要将其与所有分支合并。 是否有 hg 命令可以（半）自动执行此操作？
- 要了解如何在所有分支上实现特定功能（可视化代码某一区域的差异）并不容易/快速。
编译标志：
- 代码混乱，
- 没有隐式分支修订历史记录。必须手动执行此操作（提交一条消息，指示哪些产品受到影响）
您能否建议：
- 减轻我的疑虑的方法？
- 观点的优雅方法
- 结合两种方法的
不同
Say I'm creating a set of products that share much of their code but not all of it (For example: an application with multiple front ends: command line, Windows/MAC/Linux GUI, mobile (minimal) GUI, web GUI etc.)
Furthermore, lets say that the shared code cannot be easily split off and 'librarified'.
Im considering using mercurial named branches for the different products (e.g. branches: CLI,Windows,MAC,Linux,Mobile,Web) or compilation flags in code (e.g. #if (FRONT_END == CLI) #elif (FRONT_END == WEB) ...).
im not satisfied with either approaches. here are my grievances:
named branches:
- if i change a piece of shared code, i need to merge it with all branches.
is there an hg command to do this (semi-)automatically? - it is not easy/quick to see how a particular feature implemented across all branches (visualize the differences in one area of the code)
compilation flags:
- code clutter
- no implicit branch revision history. must do so manually (commit with a message indicating which products are affected)
can you suggest:
- ways to mitigate my qualms?
- a different point of view
- elegant ways to combine the 2 approaches
thanx
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我想，我已经为你准备了最好的策略。
前言：我强烈地、强烈地讨厌 ifdef'ed spaghetti-code
命名分支还不错，但是有管理上的缺点，是的。经过一番尝试和失败后，我停止了“单一代码库+乘以 MQ 补丁”的想法。使用新的 Mercurial，您甚至可以拥有多个队列，您可以使用受保护的补丁...结果您只有一个普通代码 - 许多（任何）目标
未来阅读：“Mercurial：权威指南”，第 12 章. 使用 Mercurial 队列管理变更 和 第 13 章 Mercurial 队列的高级使用
I suppose, I have best strategy for you.
Preface: I fiercely, furiously hate ifdef'ed spaghetti-code
Named branches aren't bad, but had management's drawbacks, yes. After some attempts and fails I stopped on "Single codebase + Multiply MQ patches" idea. With fresh Mercurial you can have even more than one queue, you can use guarded patches... as result you have one vanilla code - many (any) targets
Future reading: "Mercurial: The Definitive Guide", Chapter 12. Managing change with Mercurial Queues and Chapter 13. Advanced uses of Mercurial Queues