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

问题描述

场景:购买的Web应用程序，其中包含来自供应商的定期更新.然后，我们会大量自定义外观，有时会添加我们自己的功能，或者在供应商使用之前修复错误.对于版本控制，我们一直在其供应商分支"之后使用Subversion 模型，每次我们收到新版本时.这具有一个额外的好处，即我们拥有其系统的版本控制的原始副本.

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.

问题:我们想切换到Mercurial，并且可能会遵循

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.

恳求:对供应商分支" Mercurial样式的任何帮助将不胜感激.

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

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

两个单独的存储库，数据从供应商流向定制流，但从另一个方向流向.命名的分支default将是vendor中的唯一分支，而在custom中，您将同时具有default和stable.

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.

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

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'

您在vendor回购中的历史记录将是线性的，并且永远不会有您编写的任何内容.

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

现在在您要创建的custom存储库的本地克隆中:

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

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

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.

可以根据需要重复该过程，在您的历史记录和他们的历史记录之间建立良好的隔离，并使团队中的每个人都不负责接受供应商提供的新代码，而只关心标准的default/stable设置.单个仓库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屋！