从 SVN 迁移到 HG：分支和备份
我的公司现在运行svn，我们对它非常熟悉。然而，由于我们进行大量并发开发，合并可能会变得非常复杂。我们一直在使用 hg，我们真的很喜欢基于每个功能进行快速有效的克隆的能力。
在转向 hg 之前，我们需要解决两个主要问题：
- 为以前的 svn 用户提供分支 我熟悉 <在 Mercurial 中进行分支的 4 种方法> a href="http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/" rel="nofollow noreferrer">Steve Losh 的文章。我们认为我们应该“具体化”分支，因为我认为开发团队会发现这是从 svn 迁移的最直接的方式。因此，我想我们应该遵循“克隆分支”模型，这意味着在服务器上为分支创建单独的克隆。虽然这意味着每个克隆/分支都需要在服务器上进行并单独发布，但这对我们来说并不是太大的问题，因为我们习惯于检查 svn 分支，这些分支会作为单独的副本下来。然而，我担心在此模型中的分支之间合并更改和跟踪历史可能会变得困难。
- 备份 如果我们团队的程序员对一个分支进行本地克隆，他们如何备份本地克隆？我们习惯于在功能分支上看到这样的 svn 提交消息“临时提交：数据库功能尚未工作”。我看不到在 hg 中轻松做到这一点的方法。
非常感谢您的建议。罗里
My company runs svn right now and we are very familiar with it. However, because we do a lot of concurrent development, merging can become very complicated.. We've been playing with hg and we really like the ability to make fast and effective clones on a per-feature basis.
We've got two main issues we'd like to resolve before we move to hg:
- Branches for erstwhile svn users I'm familiar with the "4 ways to branch in Mercurial" as set out in Steve Losh's article. We think we should "materialise" the branches because I think the dev team will find this the most straightforward way of migrating from svn. Consequently I guess we should follow the "branching with clones" model which means that separate clones for branches are made on the server. While this means that every clone/branch needs to be made on the server and published separately, this isn't too much of an issue for us as we are used to checking out svn branches which come down as separate copies. I'm worried, however, that merging changes and following history may become difficult between branches in this model.
- Backup If programmers in our team make local clones of a branch, how do they backup the local clone? We're used to seeing svn commit messages like this on a feature branch "Interim commit: db function not yet working". I can't see a way of doing this easily in hg.
Advice gratefully received. Rory
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
好吧，您已经决定要将分支保留在单独的克隆中，但这并不是免费的。但设置一个存储库级别的配置文件来为所有克隆添加别名以方便 pusing/pull 并不是什么大问题。
这是实际使用 DVCS 的首要原因，因为它完美支持此用例。提交是本地的，直到您推送它们为止。这意味着每个开发人员都可以创建他认为合适的尽可能多的“临时”提交。但这并不是原始意义上的“备份”，它更像是个人开发人员的“保存点”。到目前为止，您的历史记录中充满了与团队中所有开发人员共享的临时提交。使用 Mercurial 队列，您可以轻松地将所有这些临时提交“折叠”在一起，然后再推送它们，从而在中央存储库中生成干净的历史记录。
如果真正的备份（从某种意义上说：如果这台开发机器着火会发生什么）是一个问题，那么答案很简单：只需为每个开发人员提供一个私人服务器存储库，他可以定期推送到其中。
Well, you have decided you want to keep branches in separate clones and that doesn't come for free. But it's no a big trouble to set a repository level config file that aliases all the clones to ease pusing/pulling.
That's the number one reason actually to use a DVCS because it supports this use case perfectly. Commits are local until you push them . That means that every developer can create as much "interims" commits as he sees fit. BUT that is not a "backup" in the original sense, it's more like a "savepoint" for the individual developer. Until now you cluttered your history with those interims commits that got shared to all developers on your team. Using mercurial queues you can easily "fold" all those interims commits together before pushing them, leading to a clean history in your central repository.
If real backup (in the sense of: what happens if this dev machine catches fire) is a concern the answer is simple: Just give each developer a private server repository where he can regularly push to.
我无法谈论你的 svn 分支迁移问题。你的解决方案听起来不错，但并发性非常非常困难，而且我还没有充分考虑你的情况，无法说。
但是假设您确实在服务器上为每个“svn-branch”创建了一个单独的存储库，那么我相信您可以非常轻松地解决第二个问题。首先，按照 Peter Loron 的建议复制进行工作的文件。然后，每当开发人员准备好提交“我们团队基于服务器的存储库”*时，他们就可以提交，就像“hg-branch”一样：在同一存储库内。您将获得相同类型的“临时提交：数据库功能尚未工作”的提交，但它们不会出现在主干上，从而搞砸每个人的构建。
所有这些工作的关键，也是 hg/git 如此酷的原因，是当该功能真正完成时，您可以将该“hg-branch”合并回同一存储库中的主干，并且机会要好得多与 SVN 相比，自动合并会正常工作。
I can't speak to your svn branch migration problem. Your solution sounds ok, but concurrency is VERY VERY HARD, and I haven't thought about your situation well enough to say.
But assuming you do make a separate repository on the server for each "svn-branch", then I believe you can solve your second problem very easily. First, follow Peter Loron's advice by copying the files to do work. Then, whenever a developer is ready to commit to "our team's server based repository"* then they can commit, just as an "hg-branch": within the same same repository. You'll get the same kind of commits of "Interim commit: db function not yet working" but they won't be on the trunk screwing up everyone's build.
The key to all of this working, and the reason hg/git are so cool, is that when the feature is ACTUALLY DONE, you merge that "hg-branch" it back into the trunk within the same repository, and chances are far better than with SVN that the automated merge will JUST WORK.
如果需要大量并发开发，就需要使用分布式版本控制系统、ClearCase、或者Perforce。 ClearCase 和 Perforce 不进行分布式版本控制，但它们确实比大多数其他工具更好地处理合并。
ClearCase 的合并是为并发开发而设计的，并且工作得非常好。事实上，ClearCase 中的大多数开发人员都在自己的分支上进行开发，然后在完成工作后将其更改合并到集成流中。 ClearCase 之上的 UCM 层只是自动执行此行为。
Perforce 的合并更适合他们所说的“发散分支”，但它似乎可以很好地处理并发开发。
Subversion 是一个很好的版本控制系统。我经常使用它，而且价格无可比拟，但让我们面对现实吧，在 Subversion 中合并仍然非常非常粗糙。使用属性来跟踪合并是非常hackish的。当您查看日志时，您会看到许多更改仅仅是由于 Subversion 更改了 svn:merge 属性，即使文件基本上不受影响。另外，您必须知道何时使用 --reintegrate 标志。
当然，分布式版本控制系统可以轻松地处理并发开发。这就是它们从一开始就被设计的方式。
我唯一的问题是你为什么要做这么多并发开发？多年来，我发现强迫开发人员共同完成同一组更改的效果最好。当被迫使用同一组代码时，开发人员会更加谨慎地进行开发。他们咬的东西更小，对变化更加谨慎，并且彼此之间有更多的沟通。
当我在 ClearCase 中与开发人员一起工作时，每个开发人员都有自己的分支，我常常四处走动并确保开发人员定期合并他们的更改。当没有人，但你正在更改代码时，编程会容易得多。开发人员只需在自己的分支上完成所有工作，而无需获得其他开发人员所做的更改。您有 20 名开发人员都在这样做，并且您在主分支上没有看到任何变化。然后，在我们交付之前，开发人员将对所有更改进行大规模合并。随之而来的是欢闹。
我们将在下周尝试清理所有内容并使开发人员的所有更改一起工作。 QA 很沮丧，因为他们几乎没有时间进行测试。未经测试就发送版本的情况并不罕见。毕竟，我们还有最后期限要满足。
进行并发开发有充分的理由，但我发现很多时候是开发人员提出要求，因为这使他们的工作更轻松。他们不必协调他们的更改，因为现在这是您的工作。毕竟，这就是他们付给你大笔钱的原因。
嗯，不是真正的大钱，但你的薪水比很多人都高。也许不是开发商，但你比公司里的其他人（比如看门人）赚得更多——除非他属于工会。好吧，你可以获得股票期权。
If you need a lot of concurrent development, you need to use a distributed version control system, ClearCase, or Perforce. ClearCase and Perforce don't do distributed version control, but they do handle merges probably better than most other tools out there.
ClearCase's merge is made for concurrent development and works extremely well. In fact, most developers in ClearCase develop on their own branch, then merge their changes into the integration stream when what they're working on is complete. The UCM layer on top of ClearCase simply automates this behavior.
Perforce's merging is more tuned to what they call divergent branching, but it seems to handle concurrent development okay.
Subversion is a nice version control system. I use it a lot, and you can't beat the price, but let's face it, merging in Subversion is still very, very rough around the edges. The use of properties to track merging is very hackish. When you look at logs, you see lots of changes simply due to Subversion changing the svn:merge property even though the files were basically unaffected. Plus, you must know when to use the --reintegrate flag.
Of course, distributed version control systems handle concurrent development with aplomb. It's the way they were designed from the start.
My only question is why are you doing so much concurrent development? Over the years, I've found forcing developers to work together on the same set of changes simply works the best. When forced to work on the same set of code, developers are more careful with their development. They take smaller bites, are more careful about changes, and communicate more with each other.
When I was working with developers in ClearCase, and each developer had their own branch, I use to go around and make sure developers were merging in their changes on a regular basis. It is so much easier to program when no one, but you is changing the code. Developers would simply do all their work on their branch without every getting the changes the other developers had made. You have 20 developers all doing this, and you see no changes on the main branch. Then right before we had a delivery, the developers would then make massive merges of all their changes. Hilarity ensued.
We would spend the next week trying to clean everything up and getting all of the developer's changes to work together. QA was upset because they had almost no time for testing. It wasn't uncommon to send the release out untested. After all, we had deadlines to meet.
There are good reasons to have concurrent development, but I've found many times it is the developers who request it because it makes their job easier. They don't have to coordinate their changes because it is now your job. After all, that's why they pay you the big money.
Well, not the really big money, but you're paid more than a lot of people. Maybe not the developers, but you make more than other people at your company like the janitor -- unless he belongs to a union. Well, you get stock options.
建议：也检查一下 git。
对于任何分布式版本控制系统（例如 hg 或 git），存储库的本地副本包含工作文件和本地存储库。这可能就是您想要的所有备份。如果您需要更多文件，只需将文件（包括 .hg 或 .git 目录中的存储库文件）复制到您的备份位置即可。
Suggestion: also examine git.
With any distributed version control system like hg or git, your local copy of the repo contains both the working files and the local repository. That may be all the backup you want. If you need more, simply copy the files (including the repo files in the .hg or .git directory) to your backup location.