在使用 Mercurial 的多模块项目中维护分支和标签
我正在使用一个包含许多模块的应用程序，每个模块都有自己的 Mercurial 存储库。
我最初认为将模块放在单独的存储库中是件好事，但在几次发布之后，我觉得有些不对劲。在所有模块中创建分支和标签确实很痛苦。
大多数（如果不是全部）模块都遵循类似的发布周期。
我应该继续为所有模块使用单个存储库吗？或者有更好的方法吗？
I'm working in a application with many modules each having it's own mercurial repository.
I initially thought it's good to have the modules in individual repositories but after a couple of releases, I feel something is not right. It's really a pain to create the branches and tags in all the modules.
Most, if not all modules follow a similar release cycle.
Should I go ahead and use a single repository for all the modules? Or is there a better way?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
所有模块的单个存储库意味着它们在开发生命周期中紧密耦合：
如果“v1.2”为你的软件对于你的每个模块都有一定的意义，那么是的，将它们全部放在一个存储库中是有用的。
如果某些模块处于 v2.4，而另一个模块处于 v3.6，另一个模块处于“v4.5”，并且...，则最好将独立模块声明为子存储库。
Lasse V. Karlsen 评论：
这是正确的，因为所述组件和通用框架库的开发生命周期与主程序完全无关
但是OP补充道：
因此，其中一些模块（“核心模块集”）可以保留为子存储库（独立存储库）由父存储库和主项目引用）。
其他可以直接合并到父存储库中（有点像 git 子树合并策略）以及您提到的 Hg 提示：“合并存储库"
A single repository for all modules means they are tightly coupled in their development lifecycle:
If "v1.2" for your software has any meaning for each and everyone of your modules, then yes, having them all within one repo is useful.
If some modules are at v2.4 while another is at v3.6, and another at "v4.5", and..., then having independent modules declared as subrepos is best.
Lasse V. Karlsen comments:
Which is right, since the development lifecycle of said components and general framework libraries is completely unrelated to the one of the main program
But the OP adds:
So some of those modules (the "set of core modules") can be kept as subrepos (independent repos referenced by the parent repo and main project).
The others can be merged directly into the parent repo (kind of like the git subtree merge strategy) with the Hg tip you mention: "Combining Repositories"
如果所有这些模块都属于一个项目，那么它们应该有一个存储库。模块代码可以分组在单个存储库内的目录中。
[编辑：基于评论]
结构如下：
在这种情况下，平台或核心模块的开发速度可能与应用程序模块不同。最好将它们隔离到单独的存储库中。最初，它们可能遵循相似的发布周期，这看起来确实很诱人，但在任何典型的平台/应用程序开发中，它们确实是独立的并且不同步。至少我的经历是这样。
If all these modules belong to a single project they should have a single repository. The module code can be grouped in directories within a single repo.
[Edit: based on comments]
The structure looks like :
In such a case, the platform or core module can develop at a different speed than app modules. It is better to segregate them into separate repositories. Initially, it does look enticing that they both may follow similar release cycle but in any typical platform / application development, they do go out independently and out of sync. At least that has been my experience.
，因为这确实根本不需要（“在所有模块中”）。
如果您使用 Subrepo（或者更好的是 GuestRepo - 完全为您的用例创建并作为某些subrepo 的缺点）扩展，并且您的产品是“SuperRepo”，其中仅包含链接的 sub|guestrepos，那么：
对于所有子存储库的 Superrepo 状态中的每个变更集都是已知且预定义的（每个定义包含外部仓库的变更集 ID）。因此：
从灵活性和可管理性的角度来看，我仍然更喜欢为每个低级模块使用单独的repo（自给自足的对象，没有外部依赖）和GuestRepo来收集产品中的模块并进行管理产品在其生命周期中 - 我在这里看不到“分支|标记噩梦”
Because this really not needed at all ("in all modules").
If you use Subrepo (or, better, GuestRepo - created exactly for your use-case and as compensation of some subrepo's drawbacks) extension and your Product is "SuperRepo", which contain only linked sub|guestrepos, then:
For every and each changeset in Superrepo state of all child-repos is known and predefined (each definition contain changeset-ID of foreign repo). Thus:
From POV of flexibility and manageability I still prefer separate repo for each low-level module (self-sufficient object, without external dependences) and GuestRepo for collecting modules in Product(s) and managing Product in it's lifecycle - I can't see "branching|tagging nightmare" here