Mercurial 通用/本地文件
我已经是 hg 用户几年了，对此我很高兴！
我必须开始一个我以前从未做过的项目。 我们的想法是开发一个具有批处理模式和 GUI 的软件。
因此，批处理模式和 GUI 模式都有共同的源，但每种模式也都包含特定的源。 而且，基本上，我希望我的同事能够克隆 GUI 版本，对其进行处理并提交更改。 然后，我希望能够将他们对公共文件的更改与批处理版本合并。
我该如何处理呢？
因为我已经阅读了一些关于这个主题的内容，所以我非常感谢任何帮助！
谢谢。 比努阿
I'm an hg user since a couple a years and I'm happy about that!
I have to start a project as I never did before.
The idea is to develop a software with a batch mode and an GUI.
So there will be common sources to both batch and GUI mode but each one will also contain specific sources.
And, basically, I would like my coworkers to be able to clone the GUI version, work on it an commit changes.
Then, I'd like to be able to merge their changes on the common files with the batch version.
How can I deal with that?
Since I've been reading a bit on this topic, I would really appreciate any help!!
Thank you.
binoua
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
作为子存储库的创建者，我强烈建议反对为此使用子存储库。
虽然子存储库可用于将较大的项目分解为较小的部分，但子存储库所涉及的额外复杂性和脆弱性往往会抵消这样做的好处。除非您的项目非常大，否则为了简单起见，您应该只使用一个项目存储库。
那么子存储库有什么用呢？子存储库最适合管理其他独立项目的集合。例如，假设您正在构建一个围绕现有 SCM 的大型 GUI 工具。我建议你像这样构建它：
在这里，你在一个普通的旧存储库（scm-gui）中完成所有工作，但使用更高级别的主存储库来管理构建/打包/版本控制/标记/发布整个收藏。主
scm-gui-build存储库只是其他普通存储库的一个薄包装，这意味着如果出现问题（例如存储库的 URL 之一离线），您可以继续在项目中工作而不会出现问题。（另请参阅：https://www.mercurial-scm.org/wiki/Subrepository#推荐)
As the creator of subrepos, I strongly recommend against using subrepos for this.
While subrepos can be used for breaking up a larger project into smaller pieces, the benefits of this are often outweighed by the additional complexity and fragility that subrepos involve. Unless your project is going to be really large, you should just stick to one project repo for simplicity.
So what are subrepos for, then? Subrepos are best for managing collections of otherwise independent projects. For instance, let's say you're building a large GUI tool that wraps around an existing SCM. I'd recommend you structure it something like this:
Here you do all your work in a plain old repo (scm-gui), but use a master repo at a higher level to manage building/packaging/versioning/tagging/releasing the whole collection. The master
scm-gui-buildrepo is just a thin wrapper around other normal repos, which means that if something breaks (like one of the repo's URLs goes offline) you can keep working in your project without problems.(see also: https://www.mercurial-scm.org/wiki/Subrepository#Recommendations)