如何在 Mercurial 中维护客户之间的多条开发线？
我致力于为多个客户维护相同的电子商务网络应用程序。
最初有一组标准页面，过去所有其他客户定制都是从中派生的。
最近我工作的地方决定使用Mercurial进行版本控制。他们还决定重新设计我们电子商务的标准页面集，并将其作为开发的主线/基线。
话虽这么说，我们每个客户都有一些现有的定制，这些定制是在基线页面集之前进行的，尚未进入版本控制 (hg)。
将开发基线的更改合并到单独的开发线中的最佳方法是什么？为每个客户进行开发，同时为每个客户保留现有的定制？
I work on maintaining the same e-commerce web-app for multiple customers.
Originally there was a standard set of pages from which all the rest of the customers customizations were derived in the past.
Recently the place where I work decided to use Mercurial for version control. They've also decided to re-work the standard set of pages for our e-commerce and make them a main-line/base-line of development.
That being said there are existing customizations for each of our customers that were made before the base-line set of pages, which have not been entered into version control (hg) yet.
What is the best way to merge the changes from the base-line of development into a separate line of development for each of our customers while we keep the existing customizations for each customer?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
就像任何其他分支场景一样。例如：
just like in any other branching scenario. e. g.:
根据您需要每个项目的自定义程度，最简单的方法可能是为每个客户提供一个优先于基本集的单独模板树。 与对于任何页面一样
，首先搜索客户的目录。为此，您不需要大量的版本控制魔法，但子存储库可能会很方便。
您可以使用
mq（Mercurial 队列）将每个客户的更改作为补丁集进行跟踪。合并补丁集可能有点棘手。您可以使用
rebase做同样的事情，可能比mq，但我不确定如何共享变基集。或者，您可以简单地保留一个基础存储库，并将每个客户的存储库分开，这些存储库永远不会被拉回到基础中。
在每种情况下，如果您组织项目以限制每个客户的定制，那么您的生活（合并）就会容易得多，这样它们就不太可能与核心产品的更改发生冲突。
Depending on how custom you need each project to be, the easiest way may be to have a separate tree of templates for each customer that takes precedence to the base set. As in
For any page, the customer's directory gets searched first. You shouldn't need a lot of version control magic for this, but subrepositories might be convenient.
You may be able to keep track of each customer's changes as a patchset using
mq(Mercurial queues). It can be a bit tricky to merge patchsets.You could do the same thing with
rebase, potentially more elegant thanmq, but I'm not sure how to share rebase sets.Or you could simply keep a base repository and separate repositories from each customer that are never pulled back into the base.
In each case, your life (merging) will be much easier if you organize your project so the per-customer customizations are confined so they are less likely to conflict with changes to the core product.
我会 - 并且已经 - 有一个公共存储库并为新客户克隆它。当您有一个补丁应该进入公共存储库时——或者一组补丁需要从公共存储库应用到客户的存储库时——您可以使用 hg 移植。
I would - and have - have a common repository and clone that for a new customer. When you have a patch that should go into the common repository -- or a set of patches that need to be applied from the common to a customer's repo -- you could use hg transplant.