目前，我们有一个小型开发团队使用 TFS 进行版本控制。我正在评估我们转向 DVCS 的可能性，并且想知道如果我们转向 DVCS，我们是否需要放弃当前系统中我们喜欢的一些东西，或者我们是否可以找到一种方法来支持它。
现在我们有一个稳定分支，每个开发人员有 1 个分支（您可以将每个开发人员的分支视为一个功能分支，可以在功能之间重用）。我们喜欢的东西是：
1）每次开发人员检查其分支的更改时，我们都会对服务器上的所有内容进行构建和测试，然后将所有项目自动部署到开发人员测试环境。
2）从任何开发分支合并到稳定分支都是由我完成的，这样我就可以在提交更改之前最后一次检查我们的稳定分支发生了什么。
3）如果我想帮助开发人员做某事，我可以从他们的分支获取最新版本并在我的机器上查看。
我试图了解这如何与 DVCS 一起使用（特别是我们正在使用 Mercurial 进行测试）。
我希望能够实现这样的目标：
1）我们设置了一个中央存储库，除了为每个开发人员创建 1 个分支之外，我们还创建了 Main 和 Release 分支。
2) 所有开发人员将存储库克隆到本地计算机。
3) 所有工作都是在他们的个人分支中针对本地存储库完成的。
4) 完成后，将从中央存储库中提取数据，并执行从 Main 到其分支的本地前向集成合并，以将过去发生的任何更改集成到 Main。
5) 然后他们会将更改推送到中央存储库。
6) 某些 CI 服务会接收此更改，从而导致该分支中的所有项目进行构建/测试/部署到开发。
7）如果一切正常，开发人员会给我发一封电子邮件，说他们的分支已准备好合并到主分支。
8）然后我可以合并他们的更改，或者通过某种方式直接连接到删除存储库，或者通过执行拉->合并->推送。
因此，为了处理我们的请求：
1）我假设有一些 CI 工具可以监视 Mercurial 中的分支，并启动构建/测试/部署过程（如 CC.Net）。
2) 我仍然可以通过连接到远程存储库或通过本地存储库拉取、合并和推送来管理从 DevX 到 Main 的最终合并过程。
3）我相信我可以直接从另一个开发人员的存储库中提取更改，或者我可以从中央存储库中提取更改，然后更新我的工作目录以处理他们的代码。
那么我的说法基本正确吗？
Right now, we have a small team of developers using TFS for our version control. I'm evaluating the possibility of us moving to a DVCS, and am wondering if we'd need to give up some of the stuff we like about our current system if we moved to DVCS, or if we can find a way to support it.
Right now we a Stable branch, and 1 branch for each developer (you can think of each dev's branch as a feature branch that is reused from feature to feature). The stuff we like is:
1) Each time a dev checks in changes to his branch, we do a build and test of everything on the servers, followed by automatic deployment of all projects to that developers test environment.
2) Merging from any dev's branch to Stable is done by me, so that I can have 1 last check on what is happening to our stable branch before committing the changes.
3) If I want to help a dev with something, I can just grab latest from their branch and look at it on my machine.
I'm trying to understand how this could work with a DVCS (specifically we are testing with Mercurial).
I'm hoping to be able to pull off something like this:
1) We setup a central repository, and we create Main and Release branches in addition to 1 branch for each developer.
2) All devs clone the repository to their local machine.
3) All work is done in their personal branch against the local repository.
4) When they are done, the would pull from the central repository, and perform a local forward integration merge from Main to to their branch, to integrate any changes that have happened in the past to Main.
5) They would then push their changes to the central repository.
6) Some CI service would pickup this change, causing a build/test/deploy-to-dev of all our projects in that branch.
7) If everything was ok the dev would shoot me an email saying their branch was ready for merging to Main.
8) I could then merge in their changes, either by somehow connecting directly to the remove repository, or by doing a pull->merge->push.
So to deal with our requests:
1) I'm assuming there is some CI tools that can watch a branch in Mercurial, and kick off a build/test/deploy process (like CC.Net).
2) I can still manage the final merge process from DevX to Main either by connecting to the remote repo, or by pulling, merging and pushing through my local repo.
3) I believe I could either pull changes directly from another dev's repo, or I could just pull from the central repo, and then update my working directory to work on their code.
So do I have this mostly right?
发布评论
评论（1）
是的，你有这一切权利。关于您的最终假设：
1) 有一个 用于 CruiseControl.NET 的 Mercurial 源代码控制块。我听说过与 Mercurial 一起使用的另一个 CI 服务器是 Jenkins。
2)正确。为了与
Main集成，我更喜欢在推送之前在我自己的机器上拉取（从任一机器）并合并，而不是在服务器上合并。3) 正是如此。
听起来您的开发人员相当有纪律，但以防万一您需要更好地控制操作的某些方面：
Main时发出警告。进程内挂钩必须用 Python 编写，但它们可以通过这种方式访问 Mercurial API。您还可以在服务器上放置挂钩，拒绝包含某些用户未完成的到Main合并的推送。每个开发人员一个分支是很好的。每个功能一个分支也很有用，允许每个开发人员并行处理多个事情，然后在完成后将每个事情合并到他们的分支。他们只需要记住在执行此操作之前关闭该功能分支，这样分支名称就不会不断弹出。这也可以通过克隆来完成，但我发现自己更喜欢命名分支，因为我必须保持工作/备份/笔记本电脑开发克隆全部同步，这样我就可以随时随地进行任何工作。我仍然首先作为克隆人做一些消耗性的工作。
Yep, you have all that right. Regarding you final assumptions:
1) There's a Mercurial Source Control Block for CruiseControl.NET. Another CI server I've heard of in use with Mercurial is Jenkins.
2) Correct. For integration with
Main, I would prefer pulling (from either) and merging on my own machine before pushing, rather than merging on the server.3) Exactly so.
It sounds like your developers are fairly disciplined, but just in case you need better control certain aspects of your operations:
Main. In-process hooks have to be written in Python, but they have access to the Mercurial API that way. You could also place hooks on the server that reject pushes containing a merge toMainnot done by certain users.A branch per developer is good. A branch per feature is also useful, allowing each developer to work on multiple things in parallel, then merging each to their branch when done. They just have to remember to close that feature branch before doing so, so the branch name doesn't keep popping up. This can be done with with clones as well, but I find myself preferring named branches since I have to keep work/backup/laptop development clones all synced so I can work on whateve, whenever. I still do expendable work as a clone first.