Mercurial：多客户项目的存储库布局
我们为多个客户部署了这个 webapp 产品，并考虑从 svn 切换到 Mercurial。在 svn 中，我们将主干视为项目的“核心”，而分支是为每个客户设置的。
现在我想知道 Mercurial 中最好的仓库布局是什么。
假设该项目基本上由三个主要文件夹组成：html、css、js。
虽然 /html 的内容在不同客户之间保持不变，但我们在 /css 和 /css 中进行了自定义。 <代码>/js。
现在，这些自定义项位于单独的文件中，例如 skin.css，因此我们可以清楚地区分真正的专用自定义项和对核心/通用文件的修复/更改。
然后，SVN 让我们将部分更改从客户分支提交回主干，这样我们就可以在处理客户项目时修复全局问题。据我了解，目前 Mercurial 不支持部分提交。
那么，我们如何最好地处理 Mercurial 中的这种情况呢？ 我们是否应该拥有一个中央核心存储库（可能带有发布分支）并将客户项目克隆为单独的（远程）存储库？ 拥有全部核心和核心是不是更好？客户分支机构 - 在一个仓库内？
非常感谢您的指点！
We have this webapp product being deployed for multiple customers and think about switching from svn to mercurial. In svn, we see the trunk as our projects 'core', while branches are setup for each customer.
Now I wonder what the best repo layout might be in mercurial.
Lets say the project basically is made out of three main folders: html, css, js.
While the contents of /html stay the same across customers, we have customizations in /css & /js.
Right now these customizations live in separate files, such as skin.css, so we can clearly tell the real on-purpose-customizations from fixes/changes to the core/common files.
SVN then lets us partially commit changes from customer branches back to the trunk, so we can fix global stuff while working on customer projects. As I understand, partial commits are not supported in mercurial right now.
So, how do we best approach this situation in mercurial?
Should we have one central core repo(possibly with release branches) and clone customer projects as separate (remote) repos?
Is it better to have all - core & customer branches - inside one repo?
Thanks a lot for any pointer!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我会将项目分为两个存储库：核心（html）和客户（css、js）。 “核心”很容易理解。对于“客户”，我会从一组通用或备用样式开始。然后为每个客户克隆通用样式。要为一个客户进行构建，您需要从核心和该客户克隆中提取。这样，不同的客户被隔离，但仍然通过通用风格相互了解。因此，如果您想要为所有客户更改任何样式，您只需承诺通用样式并让每个客户克隆即可。我不会为不同的客户提供完全不同的存储库。
拥有一个存储库的问题是，每当您为一位客户创建克隆时，您都会携带不相关的部分（html）。而且意外的修改很容易泄露到 html 中。出于同样的原因，即使在 SVN 中，您的项目也可能应该拆分为两个项目。
I would split the project to two repos: core (html) and customer (css, js). "core" is easy to understand. For "customer", I would start with a generic or fallback set of styles. Then make a clone off the generic styles for each customer. To make a build for one customer, you need to pull from both core and that customer clone. This way different customers are isolated but still know about each other through the generic style. So if there's any style you want to change cross all customers, you just need to commit to the generic styles and let each customer clone pull. I wouldn't make different customers totally different repos.
The problem with having one single repo is whenever you make a clone for one customer, you carry around an irrelevant part (html). And unexpected modifications can be easily leaked into html. For the same reason, your project should probably have been split to two projects even in SVN.