供应商分支，Mercurial 风格？

发布于 2024-09-28 18:29:07 字数 589 浏览 5 评论 0原文

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

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

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

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

混吃等死 2024-10-05 18:29:07

正如您所描述的那样，使用命名分支是一个不错的选择（尽管

： >http://host/hg/vendor
http://host/hg/custom

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

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

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

您在该 vendor 存储库中的历史记录将是线性的，它永远不会有你写的任何东西。

现在，在 custom 存储库的本地克隆中，您需要执行以下

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。

可以根据需要重复该过程，在您的历史记录和他们的历史记录之间提供良好的分离，并让团队中的每个人不负责接受供应商的新代码删除，而只关心正常的默认/稳定 在单个存储库中进行设置，http://host/hg/custom。

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.

回复收藏 0 原文

十六岁半 2024-10-05 18:29:07

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

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

I would use a vendor branch as an additional branch to the default+stable ones. In the end it would look something like this:

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

回复收藏 0 原文

~没有更多了~