带 SUBREPOS 的 Mercurial 分支存储库
我试图确定人们如何使用“分支存储库”，同时也使用子存储库。
假设我有一个包含解决方案文件 (.NET) 的存储库 Main，并填充了子存储库 A、B、C：
/Main
- A
- B
- C
MainSolution.sln
A、B 和 C 在其他“主”存储库之间共享时，非常紧密地集成到主项目中。因此，主存储库的一个主要功能将需要对子存储库进行修改（即，它们是共享库，但开发非常积极）。
现在是时候添加一个功能了。这一功能对于一个人来说太大了，无法处理，因此需要将代码推送到中央存储库，以便其他人可以提供帮助。我们还需要能够在功能开发开始之前返回到最后一个“稳定”代码，以防需要修复错误。我相信此时我有两个选择：(1) 在 Main 存储库中创建一个命名分支，或者 (2) 创建 Main 的新克隆。由于存在子存储库，这两个选项都会产生通常不存在的影响。
选项 1）我认为，创建命名分支将允许提交/推送对子存储库的修改，但只有在 Main 克隆中也更新到该分支的其他人才会受到影响，因为 .hgsubstate 文件被跟踪。然而，子存储库将获得一个新的头，因此（可能的）实验性功能最终将被推送到中央存储库。我的理解正确吗？
选项 2）有许多拥护者“不要使用命名分支，使用‘分支存储库’”，它们实际上是主存储库的克隆，但命名不同并存在于中央服务器上。这对我来说有点有吸引力，因为它似乎使事情分开（因此远离灾难，因为同事——还有我自己！——仍在学习 Mercurial）。但是，当涉及子存储库时，此工作流程似乎完全被破坏，因为创建主存储库的克隆不会创建新的、独立的子存储库克隆。它是一个新的克隆，但它仍然指向相同的子存储库，因此对它们所做的更改将找到返回到子存储库的方式！我意识到这是设计使然，这是 Mercurial（对我来说）非常酷的事情之一。但是人们到底如何将这个分支存储库工作流程与子存储库一起使用呢？完全不可思议的是，对于每个功能/实验/版本/无论什么，我将创建主存储库的一个新克隆（在中央服务器上），并创建子存储库的克隆（在中央服务器上），并且修改所有 .hgrc/.hgsub 路径以指向正确的中央存储库。
此时，我只是想了解人们如何处理复杂的项目并将子存储库与分支存储库一起使用。有什么想法吗？
I'm trying to determine how people use "branch repositories" while also using subrepos.
Let's say I have repo Main containing a solution file (.NET), and populated with subrepos A, B, C:
/Main
- A
- B
- C
MainSolution.sln
A, B, and C, while being shared between other "Main" repos, are very tightly integrated into Main project. Thus, a major feature to the Main repo will require modifications to the subrepos (i.e., they are shared libraries, but are very actively developed).
Now it is time to add a feature. This feature is too big for one person to handle, and thus the code will need to be pushed to the central repo so others can help. We'd also need to be able to go back to the last "stable" code before the feature development began in case a bugfix is needed. I believe I have two options at this point: (1) create a named branch in the Main repo, or (2) create a new clone of Main. Since there are subrepos, both of these options have repercussions not present typically.
Option 1) Creating a named branch will, I presume, allow modifications to the subrepos to be committed/pushed, but only other people who have also updated to that branch in their clone of Main will be affected, since the .hgsubstate file is tracked. However, the subrepos will get a new head, and thus the (possibly) experimental feature would end up getting pushed to the central repo. Am I understanding this correctly?
Option 2) There are numerous advocates for the "don't use named branches, use 'branch repositories'", which are literally clones of the main repo, but named differently and existing on the central server. This is a little appealing to me, as it seems to keep things separated (and thus detached from disaster as co-workers --and myself!-- are still learning Mercurial). But this workflow seems completely broken when subrepositories are involved, since creating a clone of the Main repo does not create new, separated clones of the subrepos. It's a new clone, but it's still pointing at the same subrepos, and thus changes made to them will find their way back into the subrepos! I realize this is by design, and it's one of the really cool things (to me) about Mercurial. But how on earth do people use this branch repository workflow with subrepositories? It is completely inconceivable that, for each feature/experiment/version/whatever, I'm going to create a new clone (on the central server) of the Main repo, AND create clones (on the central server) of the subrepos, AND modify all the .hgrc/.hgsub paths to point to the proper central repos.
At this point, I'm just trying to understand HOW people work on a complicated project and use subrepos with branch repositories. Any thoughts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您还有其他选择。例如，您可以使用书签。从 1.9 版本开始，书签可以推送和拉取，它们不再只是本地的。由于您通常不希望开发“分支”在新功能完成后作为命名分支保留下来，因此书签通常是此类事情的更好选择。我倾向于使用书签来进行新的开发，并为发布的版本保存真实的分支。
您还应该注意，子存储库不能按照您描述的方式在多个主存储库之间共享。实际上，您可以将子存储库存储在主存储库中（而不是将它们与主存储库处于同一级别，或完全存储在其他位置），这将使它们独一无二 到每个主存储库，但当您想要共享这些更改时，您可以从其他主存储库中的子存储库中推送和拉取。我通常都是这样做的。
不幸的是，如果没有白板，其中大部分内容很难解释，所以如果不清楚，请告诉我。
You have other options as well. You could use bookmarks, for example. Since version 1.9, bookmarks can be pushed and pulled, they're not just local anymore. Since you often don't want a development "branch" to stick around as a named branch after that new feature is completed, bookmarks are often a better choice for that kind of thing. I tend to use bookmarks for new development and save real branches for released versions.
You should also be aware that subrepositories don't have to be shared between multiple main repositories in the way you describe. You can actually have the subrepositories stored inside a main repository (as opposed to having them at the same level as the main repos, or stored in some other location entirely), which would make them unique to each main repository, except you can push and pull from the subrepos in other main repos when you want to share those changes. This is the way I usually do it.
Unfortunately much of this is difficult to explain without a whiteboard, so please let me know if this isn't clear.
我更喜欢命名分支，因为这些功能最终很可能会合并到默认分支中。切换分支比切换存储库要容易得多。
使用命名分支，您永远不需要担心意外地将不稳定的开发分支推送到稳定的存储库中。指定的分支已经存在，但除非开发人员要求，否则不会通过更新检索。
I prefer named branches for features that will most likely eventually get merged into the default branch. It is much easier to switch branches than switch repos.
With named branches you never need to worry about accidentally pushing your unstable branch of development into the stable repo. The named branch is already there, but won't be retrieved via an update unless a developer asks for it.