15

场景：购买的 Web 应用程序，供应商定期更新。然后，我们对外观进行大量定制，有时会添加我们自己的功能或在供应商得到它之前修复错误。对于版本控制，每次收到新版本时，我们都会按照他们的“供应商分支”</a> 模型使用 Subversion 。这还有一个额外的好处，那就是我们拥有他们系统的版本控制的普通副本。

问题：我们想切换到 Mercurial，并且可能会遵循稳定/默认的分支模式。如果我们只从供应商那里收到一个版本并从那里开始开发，那么 Mercurial 就非常有意义。但是，无论出于何种原因，我都无法思考如何处理来自供应商的未来版本。

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

4

2 回答 2

14

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

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

两个独立的存储库，其中数据从供应商流向自定义，但从不向另一个方向流动。命名的分支default将是vendor和 in 中唯一一个custom同时拥有defaultand的分支stable。

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

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

Your history in that vendor repo will be linear, and it will never have anything you wrote.

Now in your local clone of the custom repo you'd do:

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

And then you do the work of merging your local chances on default with their new code drop. When you're happy with the merge (tests pass, etc.) you push from your local clone back to http://host/hg/custom.

That process can be repeated as necessary, provides good separation between your history and theirs', and lets everyone on your team not responsible for accepting new code drops from vendors, to concern themselves only with a normal default/stable setup in a single repo, http://host/hg/custom.

于 2010-10-22T16:14:58.647 回答
9

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

V1----V2-------------V3---------V4     Vendor
 \     \              \          \
  D1----D2---D3--D4-D5-D6-D7-D8---D9   default
                  \           \    \
                   S1----------S2---S3 stable
于 2010-10-22T15:04:16.710 回答