1

我目前正在使用 Mercurial 以及 Guestrepo 扩展来管理和版本化项目的不同组件。我已经有了一个相当稳定的工作流程来管理不同版本的组件。

但是，在对组件的细微变化进行版本控制时，我想不出一个有效的解决方案。例如，这是一个稍微不同的嵌入式设备驱动程序（例如不同的串行端口速度），或者一个用英语而不是德语编写的 GUI。

我不认为将它们堆叠在 Release/Stable 分支中是一个好的工作流程，因为不同配置（英语、西班牙语、中文……）的扩散可能会导致 Release 分支严重且无意义的膨胀。

另一方面，为每个分支创建一个单独的 Release 分支会导致我有很多很多分支，恕我直言，这不是最好的解决方案。

每当必须进行结构更改时，为每个配置创建单独的存储库将假设一项非常繁琐的任务，因为所有存储库都必须随着该更改进行更新。

对此有任何想法吗？

谢谢你。

正如@EldadAK 建议的那样，为每个配置创建一个存储库并从其他存储库导入核心功能似乎是个好主意。

但是，我仍然不知道如何安排“相同但略有不同”的组件，这些组件在一些细微的功能上有所不同，但它们的核心相同。

是代码架构问题吗？是否应该重构组件，以便主要核心和不同功能位于不同的组件中，这些组件使用每个配置的自定义构建相关联？

4

2 回答 2

0

IMHO, you should keep all changes in your main branch. Managing all branches or even multiple repositories is not scalable and will eventually get out of hand.

I don't think you should care about the size of your release branch. By keeping it all together, you will always know where you are, what is included in a release and when you really need to branch, have all the changes accumulated to that point.

It's my personal opinion that you should try and keep it simple to manage looking many revisions and years ahead...

Note - Project managers tend to think about next week. You need to think about next year...

I hope this helps.

于 2013-04-11T14:12:05.933 回答
0

对组件的细微变化进行版本控制时的有效解决方案

虽然我看不出在一个 repo中使用命名分支有任何严重的缺点，但您可以在 Mercurial 中使用另一种（“默认”事实上的）解决方案进行配置管理：MQ

您只需稍微采用 MQ 的工作流程（相同数量的分支，相同数量的存储库）

于 2013-04-11T15:21:17.187 回答