为什么Mercurial中的分支和合并比Subversion更容易？ [英] Why is branching and merging easier in Mercurial than in Subversion?
问题描述
我的问题源于Mercurial，您可以采用与Subversions / CVS中央存储库类似的工作方式，一切都可以正常工作。您可以在同一分支上进行多次合并，并且您不需要提交数字和标签名称的无尽纸片。
我知道最新版本的Subversion具有跟踪合并到分支机构的能力，所以你不会得到相同程度的麻烦，但它是一个巨大而重大的发展，它仍然不会完成开发团队希望它做的所有事情。
这一切都有根本性的区别。
在Subversion（和CVS）中，存储库首先是最重要的。在git
和mercurial中，在
中并没有真正的仓库概念;这里的变化是中心主题。
+1
麻烦CVS / SVN来自这样的事实，即这些系统并不是记住变化的父母。在Git和Mercurial中，
不仅可以提交多个孩子，还可以有多个
父母！
使用一个的图形工具， gitk 或 hg 。在以下示例中，分支＃2从
view
commit A处的＃1分支出来，并且自此合并了一次（在M处，与提交B合并）：
o --- A --- o --- B --- o --- C（分支＃1）
\\
o - O - 中号--- X ---？ （分支＃2）
请注意A和B有两个孩子，而M有两个父母即可。这些
关系在存储库中记录。假设
分支＃2的维护者现在想要合并分支＃1的最新更改，他们可以
发出如下命令：
$ git合并分支-1
并且工具会自动知道 base 是B - 因为它
被记录在提交M中，它是＃2尖端的祖先 - 和
，它必须合并发生的所有$ B和C之间的b $ b .CVS不记录这些信息，也没有在
版本1.5之前的SVN。在这些系统中，图
将如下所示：
o --- A --- o --- B --- o --- C（分支＃1）
\
o --- o --- M --- X ---？ （分支＃2）
其中M仅仅是一个巨大的压扁和B，
应用于M之上。请注意，在完成契约之后，没有任何痕迹
（M除外）（除了潜在的人类可读的评论）
源于，多少次提交被合并在一起 - 使得
的历史更加难以理解。
更坏仍然，执行第二次合并变成了一场噩梦：人们必须弄清楚合并基础在第一次合并时的情况（和 ）。 >
表示首先有一个合并！），然后
将该信息提供给该工具，以便它不尝试在
顶部重放A..B。所有这些在密切合作下都很困难，但在分布式环境中根本不可能是
。
一个（相关的）问题是没有回答这个问题的方法是：确实X
包含B？其中B是
潜在重要的错误修复。所以，为什么不把这些信息记录在提交中，因为
在合并时是已知的！
P.-S 。 - 我没有使用SVN 1.5+合并记录功能的经验，但是工作流程似乎比分布式系统中的
更具人造价值。如果确实如此，那可能是因为 - 正如上述评论中提到的
- 重点放在存储库组织上，而不是改变本身。
Handling multiple merges onto branches in Subversion or CVS is just one of those things that has to be experienced. It is inordinately easier to keep track of branches and merges in Mercurial (and probably any other distributed system) but I don't know why. Does anyone else know?
My question stems from the fact that with Mercurial you can adopt a working practice similar to that of Subversions/CVSs central repository and everything will work just fine. You can do multiple merges on the same branch and you won't need endless scraps of paper with commit numbers and tag names.
I know the latest version of Subversion has the ability to track merges to branches so you don't get quite the same degree of hassle but it was a huge and major development on their side and it still doesn't do everything the development team would like it to do.
There must be a fundamental difference in the way it all works.
In Subversion (and CVS), the repository is first and foremost. In git and mercurial there is not really the concept of a repository in the same way; here changes are the central theme.
+1
The hassle in CVS/SVN comes from the fact that these systems do not remember the parenthood of changes. In Git and Mercurial, not only can a commit have multiple children, it can also have multiple parents!
That can easily observed using one of the graphical tools, gitk or hg
view. In the following example, branch #2 was forked from #1 at
commit A, and has since been merged once (at M, merged with commit B):
o---A---o---B---o---C (branch #1)
\ \
o---o---M---X---? (branch #2)
Note how A and B have two children, whereas M has two parents. These relationships are recorded in the repository. Let's say the maintainer of branch #2 now wants to merge the latest changes from branch #1, they can issue a command such as:
$ git merge branch-1
and the tool will automatically know that the base is B--because it was recorded in commit M, an ancestor of the tip of #2--and that it has to merge whatever happened between B and C. CVS does not record this information, nor did SVN prior to version 1.5. In these systems, the graph would look like:
o---A---o---B---o---C (branch #1)
\
o---o---M---X---? (branch #2)
where M is just a gigantic "squashed" commit of everything that happened between A and B, applied on top of M. Note that after the deed is done, there is no trace left (except potentially in human-readable comments) of where M did originate from, nor of how many commits were collapsed together--making history much more impenetrable.
Worse still, performing a second merge becomes a nightmare: one has to figure out what the merge base was at the time of the first merge (and one has to know that there has been a merge in the first place!), then present that information to the tool so that it does not try to replay A..B on top of M. All of this is difficult enough when working in close collaboration, but is simply impossible in a distributed environment.
A (related) problem is that there is no way to answer the question: "does X contain B?" where B is a potentially important bug fix. So, why not just record that information in the commit, since it is known at merge time!
P.-S. -- I have no experience with SVN 1.5+ merge recording abilities, but the workflow seems to be much more contrived than in the distributed systems. If that is indeed the case, it's probably because--as mentioned in the above comment--the focus is put on repository organization rather than on the changes themselves.
这篇关于为什么Mercurial中的分支和合并比Subversion更容易？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
