供应商分支，Mercurial 风格? [英] Vendor Branching, Mercurial Style?

问题描述

场景:购买的 Web 应用程序，供应商定期更新.然后，我们会大量定制外观，有时会在供应商之前添加我们自己的功能或修复错误.对于版本控制，我们一直在使用 Subversion，遵循他们的 Vendor Branch" 每次我们收到新版本时的模型.这有一个额外的好处，即我们拥有他们系统的版本控制的普通副本.

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

请求:对供应商分支"Mercurial 风格的任何帮助将不胜感激.

解决方案

使用您所描述的命名分支是一个不错的选择(尽管 不是唯一的选择)，但我仍然建议在众所周知的位置使用一些单独的克隆来促进这个过程.假设 http://host/hg/ 是用于安装的 hgweb(以前的 hgwebdir)(尽管 ssh://也可以很好地工作，无论如何)，您将拥有如下内容:

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

两个独立的存储库，其中数据从供应商流向自定义，但从未流向另一个方向.命名分支 default 将是 vendor 和 custom 中唯一的分支，您将同时拥有 default 和 <代码>稳定.

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

hg addremovehg commit -m '来自供应商的新产品，版本号 x.x.x'

您在该 vendor 存储库中的历史记录将是线性的，并且永远不会包含您编写的任何内容.

现在在您要执行的 custom 存储库的本地克隆中:

hg update default # 更新到默认分支中的最新头hg pull http://host/hg/vendor # 引入vendor的新变化作为新的headhg 合并提示 # 将 _your_ 最新的默认 cset 与他们的新 drop 合并

然后您将默认的本地机会与他们的新代码删除合并.当您对合并(测试通过等)感到满意时，您可以将本地克隆推送回 http://host/hg/custom.

这个过程可以根据需要重复，在你和他们的历史之间提供良好的分离，并让你团队中的每个人不负责接受来自供应商的新代码，只关心正常的默认/稳定 在单个 repo 中设置，http://host/hg/custom.

The scene: A purchased web application, with regular updates from the vendor. We then, heavily customize the look and sometimes add our own functionality or fix a bug before the vendor gets to it. For version control, we have been using Subversion following their "Vendor Branch" model each time we received a new release. This has the added benefit that we have a, version controlled, vanilla copy of their system.

The problem: We would like to switch to Mercurial and will likely follow the stable/default branching pattern. Mercurial makes perfect sense if we were to only receive a single release from our vendor and start developing it from there. But, for whatever reason, I am having trouble wrapping my mind around how to handle future releases from the vendor.

The plea: Any help with "vendor branching" Mercurial style would be greatly appreciated.

解决方案

Using named branches as you've described is a fine choice (though not the only choice), but I'd still suggest using a few separate clones at well known locations to facilitate this process. Pretending that http://host/hg/ is a hgweb (formerly hgwebdir) for your install (though ssh:// works great too, whatever), you'd have something like this:

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

Two separate repos where data flow from vendor to custom but never the other direction. The named branch default would be the only one in vendor and in custom you'd have both default and stable.

When you got a new code drop from the vendor you'd unpack it into the working directory of the vendor repo, and then run:

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.

这篇关于供应商分支，Mercurial 风格?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！