Mercurial如何与许多开发人员一起工作? [英] How does Mercurial work with many developers?
问题描述
我查看了一些已知产品的Mercurial存储库，例如 TortoiseHg 和<一个href ="http://code.python.org/hg/trunk/graph" rel ="noreferrer"> Python ，尽管我可以看到多个人在进行更改，但时间轴看起来总是很干净，只有一个分支前进.
但是，假设您有14个人从事同一产品的工作，这会不会在任何给定的时间迅速进入具有14个并行分支机构的分支梦??
例如，只有两个人，并且产品位于变更集X，现在这两个开发人员都在星期一早上开始使用单独的功能，因此他们都从同一个父变更集开始.
当他们提交时，我们现在有两个分支，然后有14个人，我们很快就会有10+(可能不是14 ...)个分支，需要将它们合并回默认分支.
或者...我在这里没看到什么?也许这真的不是问题吗?
编辑:对于我在这里真正要问的内容，我感到有些困惑，所以让我澄清一下.
我非常清楚，Mercurial可以轻松地处理多个分支和合并，作为一个答案，即使人们使用相同的文件，他们也经常不在同一行上工作，即使那样，冲突仍然存在.容易处理.我还知道，如果两个人由于在同一文件中更改了很多相同的代码而最终创建了一个合并地狱，那么这里会有一些总体规划上的失败，因为我们将两个功能放到了两个开发人员的完全相同的位置，而不是尝试让他们一起工作，或者首先将两者都交给一个开发人员.
不是那样.
我很好奇的是，这些开源项目如何处理如此干净的历史记录.对我而言，不重要的是(正如一个评论想知道的那样)历史是干净的，我的意思是说，我们做是并行进行的，存储库能够反映这一点，所以更好(我认为) )，但是我看过的这些存储库没有那个.他们似乎正在使用Subversion模型，在该模型中您无法在更新和合并之前进行提交，在这种情况下，历史记录只是一条直线.
那他们怎么做呢?
它们是否重新设置"更改，以使它们似乎遵循分支的最新提示，即使它们最初是在分支历史中稍作修改的呢?移植变更集以使它们看起来像已经在主分支中提交了吗?
或者我看过的项目在添加新的东西(实际上他们一次只工作一个人)上是如此缓慢(目前，我的历史还不算很远)?
还是他们将更改推送给一位中央维护人员，由他们进行审核，然后进行整合?看起来好像不太像，因为我看过的许多项目在变更集上都有不同的名称.
在更新的问题中，您似乎对整理历史记录的方式更感兴趣.当您拥有历史记录并希望将其变成一条整齐的直线时，您可以使用 rebase ，移植和/或等待编译，因此以下是我的意思示例:
> hg init
> echo test > a.txt
> hg addremove && hg commit -m "added a.txt"
> echo test > b.txt
> hg addremove && hg commit -m "added b.txt"
> hg update 0 # go back to initial revision
> echo test > c.txt
> hg addremove && hg commit -m "added c.txt"
正在运行 hg glog 现在显示此历史(有两个分支):
@ changeset: 2:c79893255a0f
| tag: tip
| parent: 0:7e1679006144
| user: mizipzor
| date: Mon Jul 05 12:20:37 2010 +0200
| summary: added c.txt
|
| o changeset: 1:74f6483b38f4
|/ user: mizipzor
| date: Mon Jul 05 12:20:07 2010 +0200
| summary: added b.txt
|
o changeset: 0:7e1679006144
user: mizipzor
date: Mon Jul 05 12:19:41 2010 +0200
summary: added a.txt
进行重新设置，将变更集1变成2而不是0的子代:
> hg rebase -s 1 -d 2
现在让我们再次检查历史记录:
@ changeset: 2:ea0c9a705a70
| tag: tip
| user: mizipzor
| date: Mon Jul 05 12:20:07 2010 +0200
| summary: added b.txt
|
o changeset: 1:c79893255a0f
| user: mizipzor
| date: Mon Jul 05 12:20:37 2010 +0200
| summary: added c.txt
|
o changeset: 0:7e1679006144
user: mizipzor
date: Mon Jul 05 12:19:41 2010 +0200
summary: added a.txt
Presto！单线. :)
还要注意，我没有进行合并.当像这样进行基准调整时，就必须像处理合并一样处理合并冲突和所有事情.因为多数民众赞成在幕后发生的事情.在一个小型测试仓库中对此进行试验.例如，尝试更改添加到revision 0中的文件，而不仅仅是添加更多文件.
I look at Mercurial repositories of some known products, like TortoiseHg and Python, and even though I can see multiple people committing changes, the timeline always looks pretty clean, with just one branch moving forward.
However, let's say you have 14 people working on the same product, won't this quickly get into a branch nightmare with 14 parallel branches at any given time?
For instance, with just two people, and the product at changeset X, now both developers start working on separate features on monday morning, so both start with the same parent changeset.
When they commit, we now have two branches, and then with 14 people, we would quickly have 10+ (might not be 14...) branches that needs to be merged back into the default.
Or... What am I not seeing here? Perhaps it's not really a problem?
Edit: I see there's some confusion as to what I'm really asking about here, so let me clarify.
I know full and well that Mercurial easily handles multiple branches and merging, and as one answer states, even when people work on the same files, they don't often work on the same lines, and even then, a conflict is easily handled. I also know that if two people end up creating a merge hell because they changed a lot of the same code in the same files, there's some overall planning failure here, since we've placed two features in the exact same place onto two developers, instead of perhaps trying them to work together, or just giving both to one developer in the first place.
So that's not it.
What I'm curious about is how these open source project manage such a clean history. It's not important to me (as one comment wondered) that the history is clean, I mean, we do work in parallel, that the repository is able to reflect that, so much the better (in my opinion), however these repositories I've looked at doesn't have that. They seem to be working along the Subversion model where you can't commit before you've updated and merged, in which case the history is just one straight line.
So how do they do it?
Are they "rebasing" the changes so that they appear to be following the latest tip of the branch even though they were originally committed a bit back in the branch history? Transplanting changesets to make them appear to' having been committed in the main branch to begin with?
Or are the projects I've looked at either so slow (at the moment, I didn't look far back in the history) at adding new things that in reality they've only been working one person at a time?
Or are they pushing changes to one central maintainer who reviews and then integrates? It doesn't look like that since many of the projects I looked at had different names on the changesets.
In your updated question it seems that you are more interested in ways of tidying up the history. When you have a history and want to make it into a single, neat, straight line you want to use rebase, transplant and/or mercurial queues. Check the docs out for those three and you should realise the workflow for how its done.
Edit: Since Im waiting for a compile, here follows a specific example of what I mean:
> hg init
> echo test > a.txt
> hg addremove && hg commit -m "added a.txt"
> echo test > b.txt
> hg addremove && hg commit -m "added b.txt"
> hg update 0 # go back to initial revision
> echo test > c.txt
> hg addremove && hg commit -m "added c.txt"
Running hg glog now shows this (diverging) history with two branches:
@ changeset: 2:c79893255a0f
| tag: tip
| parent: 0:7e1679006144
| user: mizipzor
| date: Mon Jul 05 12:20:37 2010 +0200
| summary: added c.txt
|
| o changeset: 1:74f6483b38f4
|/ user: mizipzor
| date: Mon Jul 05 12:20:07 2010 +0200
| summary: added b.txt
|
o changeset: 0:7e1679006144
user: mizipzor
date: Mon Jul 05 12:19:41 2010 +0200
summary: added a.txt
Do a rebase, making changeset 1 into a child of 2 rather than 0:
> hg rebase -s 1 -d 2
Now lets check history again:
@ changeset: 2:ea0c9a705a70
| tag: tip
| user: mizipzor
| date: Mon Jul 05 12:20:07 2010 +0200
| summary: added b.txt
|
o changeset: 1:c79893255a0f
| user: mizipzor
| date: Mon Jul 05 12:20:37 2010 +0200
| summary: added c.txt
|
o changeset: 0:7e1679006144
user: mizipzor
date: Mon Jul 05 12:19:41 2010 +0200
summary: added a.txt
Presto! Single line. :)
Also note that I didnt do a merge. When you rebase like this, you will have to deal with merge conflicts and everything just like as if you did a merge. Because thats pretty much what happens under the hood. Experiment with this in a small test repo. For example, try changing the file added in revision 0 rather than just adding more files.
这篇关于Mercurial如何与许多开发人员一起工作?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
