我目前正在使用Mercurial以及Guestrepo扩展来管理和版本化项目的不同组件。我已经达到了一个非常稳定的工作流程来管理不同版本的组件。
但是，在版本化组件的细微变化时，我无法提出有效的解决方案。例如，这是一个略有不同的嵌入式设备驱动程序（例如，不同的串行端口速度），或者是用英语而不是德语编写的GUI。
我不认为在Release / Stable分支中堆叠它们是一个很好的工作流程，因为不同配置（英语，西班牙语，中文......）的激增可能导致Release分支的严重和无意义的膨胀。
另一方面，为每个分支创建一个单独的Release分支会引导我进入许多分支，这不是恕我直言的最佳解决方案。
每当必须进行结构更改时，为每个配置创建单独的存储库都会产生相当繁琐的任务，因为所有的存储库都必须使用该更改进行更新。
对此有什么想法吗？
谢谢。
正如@EldadAK建议的那样，为每个配置创建一个repo并从其他repos导入核心功能似乎是一个不错的主意。
然而，我仍然无法弄清楚如何安排“相同但略有不同”的组件，这些组件在一些微妙的功能上有所不同，但却分享了它们的核心。
这是代码架构问题吗？是否应重构组件，以便主核和不同的功能位于不同的组件中，这些组件使用每个配置的自定义构建相关吗？
答案 0 :(得分：0)
我认为您不应该关心发布分支的大小。通过将它们保持在一起，您将始终知道您的位置，发布中包含的内容以及当您真正需要分支时，将所有更改累积到该点。
我个人认为，您应该尽量保持简单，以便管理未来几年的修订......
注 - 项目经理倾向于考虑下周。你需要考虑明年......
我希望这会有所帮助。
答案 1 :(得分：0)
在版本化组件的细微变化时的有效解决方案
虽然在一个repo 中使用命名分支时看不到任何严重的缺点，但您可以在Mercurial中使用另一个（“默认的”事实上）解决方案进行配置管理：{{3} }
您只需稍微采用您的工作流程（相同数量的分支，相同数量的回购）到MQ