Mercurial：为什么要在单独的克隆存储库中维护单独的软件分支/版本，而不是使用标签？
我正在看 Mercurial 手册，第 6 章“使用多个分支”。作者在其中指出，如果您拥有同一软件的不同版本/分支，那么以一种隐含的明显方式将软件的每个分支托管在单独的存储库中是有意义的。
我知道 Mercurial 支持标签（据我所知，这是在 subversion 中完成分支的方式）。为什么要使用不同的存储库而不是标签来进行分支管理？
I'm looking at the mercurial handbook, chapter 6 "Working with multiple branches". In there the author states that if you have separate versions/branches of the same software that it makes sense in an implied obvious way to host each branch of the software in a separate repository.
I know that Mercurial supports tags (which is the way that branches are done in subversion AFAIK). Why would you use different repositories instead of tags for branch managing?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Mercurial 的标签与 Subversion 的分支不同。在 Subversion 中，创建分支会创建代码的单独副本（我认为至少带有硬链接），而 Mercurial 中的标签仅指向特定的提交。
不久前，我写过 Mercurial 的分支模型（其中分支与克隆是四个选项之一），也许您会发现它有用？
Mercurial's tags are not the same as Subversion's branches. In Subversion, making a branch creates a separate copy of the code (with hardlinks at least, I think) while tags in Mercurial just point to a specific commit.
A while ago I wrote about Mercurial's branching models (of which branching-with-clones is one of four options), maybe you'd find it useful?
在 Mercurial 中拥有不同的存储库有其优点，但在处理分支方面存在问题。
分支意味着多个头，那么图形就复杂得多，甚至图形表示也可能无法容纳这么多复杂的路径……而且我什至不谈论人脑！
另一方面，拥有多个存储库意味着每个存储库将具有更简单的结构，因此减轻了必须处理多个分支/合并的脑部创伤（无论如何，因为两个开发人员从同一个变更集工作并继续开发）同时）。
此外，通过多个存储库，您可以使用您使用的任何编辑器轻松读取/编辑给定存储库上的任何文件（如果您保持工作目录相对于提示而言是最新的）。
在颠覆中，你必须处理多个分支，没有其他办法，你必须使用标签。
在 Mercurial 上，标签不应该移动（它不必要地引入变更集）并且分支是现成的：你总是有分支。但是，由于您可以拥有多个存储库，因此为您提供了另一个维度。使用与否是你的选择，无论如何它让我的生活更轻松。
There are advantages in having different repositories in Mercurial, and problem in handling branches.
Branches mean multiple heads, the graphs are much more complicated then, and even the graphical representation may not be able to accommodate so many convoluted paths... and I don't even talk about the human brain!
On the other hand, having multiple repositories mean that each repository will have a much simpler structure, therefore easing the brain trauma of having to deal with multiple branches/merges (that you have anyway, since two developers working from the same changeset and onward develop concurrently).
Furthermore, with multiple repositories, you can read/edit any file on a given repository easily with whatever editor you are using (if you maintain the working dir up to date relatively to the tip).
On subversion you HAVE to deal with multiple branches, there is no other way around, and you have to use tags.
On Mercurial, tags are not supposed to move (it needlessly introduce changesets) and branches are handled off-the-shelf: you always have branches. However, since you can have multiple repositories, you are offered another dimension. It is your choice whether you use it or not, it made my life easier anyway.