Question

场景：购买的网络应用程序，定期更新供应商。然后，我们大量定制外观，有时添加我们自己的功能或在供应商到达之前修复错误。对于版本控制，我们每次收到新版本时都会按照“Vendor Branch”模型使用Subversion。这有一个额外的好处，我们有一个，版本控制，他们的系统的vanilla副本。

问题：我们想切换到Mercurial，可能会遵循stable/default branching模式。如果我们只从我们的供应商处获得一个版本并从那里开始开发它，那么Mercurial就非常有意义。但是，无论出于何种原因，我都无法理解如何处理供应商的未来版本。

请求：任何有关“供应商分支”Mercurial风格的帮助将不胜感激。

Answer 1

如你所描述的那样使用命名分支是一个不错的选择（虽然not the only choice），但我仍然建议在众所周知的位置使用一些单独的克隆来促进这个过程。假装你的http://host/hg/是一个hgweb（以前的hgwebdir）（尽管ssh：//也很好用，无论如何），你会有这样的东西：

http://host/hg/vendor
http://host/hg/custom

两个单独的repos，其中数据从供应商流向自定义，但从不向另一个方向流动。指定的分支default将是vendor和custom中唯一一个default和stable的分支。

当您从供应商处获得新代码时，您将其解压缩到vendor repo的工作目录中，然后运行：

hg addremove
hg commit -m 'new drop from vendor, version number x.x.x'

你vendor回购中的历史将是线性的，它永远不会有你写的任何内容。

现在，您将在custom repo的本地克隆中执行以下操作：

hg update default     # update to the latest head in your default branch
hg pull http://host/hg/vendor   # bring in the new changes from vendor as a new head
hg merge tip          # merge _your_ most recent default cset with their new drop

然后你将默认的本地机会与新代码丢弃相结合。当您对合并（测试通过等）感到满意时，您将从本地克隆推送回http://host/hg/custom。

可以根据需要重复该过程，在您的历史记录和他们的历史记录之间实现良好的分离，并让团队中的每个人都不负责接受供应商的新代码丢失，只关注正常的default/stable设置在单个仓库中，http://host/hg/custom。

Answer 2

我会使用供应商分支作为默认+稳定分支的附加分支。最后它看起来像这样：

V1----V2-------------V3---------V4     Vendor
 \     \              \          \
  D1----D2---D3--D4-D5-D6-D7-D8---D9   default
                  \           \    \
                   S1----------S2---S3 stable

供应商分支，Mercurial风格？

2 个答案: