您何时以及为什么会选择集中式 (SVN) 而不是分布式（Git、Mercurial）
最近在我的新工作中，我的部门（我们主要是建设股票和赛马网站，我们只在办公室做网站。）正在考虑使用SVN或Mercurial。我们的项目经理说他赞成SVN（没有给我们他的理由），但也给我们一个选择Mercurial的选择，并征求我们的意见（最终决定权仍在他手中）
鉴于网上大多数文章都是在解释为什么选择Mercurial通过 SVN（或类似的东西）。我想问相反的问题。
那么，尽管 Mercurial/Git 比 SVN 具有许多优势，但您何时以及为什么会在新项目中选择 SVN 而不是 Mercurial？
Recently in my new job, my department (we are mainly building stocks and horse racing websites and we only work on the website in office.) is considering over to use SVN or Mercurial. Our project manager says he favor SVN (didn't give us his reasons) but give us a choice to choose Mercurial too and ask us for our opinions (final decision still lies with him)
Given that most articles online are about explaining why choose Mercurial over SVN (or something similar). I would like to ask the opposite.
So when and why will you choose SVN over Mercurial in a new project despite the many advantages of Mercurial/Git over SVN?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
当我被迫服从同事的普遍意见或管理层的命令时。这是最有可能的情况。
在某些特定情况下，我会选择 Subversion 或 Perforce 而不是 Mercurial。这些与非常具体的功能有关。例如，将随机子目录本身视为存储库的能力在某些情况下可能很有用。 Perforce 在签出时重新排列目录结构的能力也很有用。 Perforce 在处理游戏开发和其他类型的媒体工作中使用的大型二进制对象方面也做得非常出色，而 Mercurial 和 Git 目前都不是特别擅长这些事情。
但总的来说，我没有其他原因为自己选择非分布式版本控制系统。我发现它们极大地限制和约束。自从我了解什么是版本控制以来，我一直对它们感到失望。从纯粹的工作流程角度来看，没有什么是分布式版本无法通过集中式版本控制系统完成的。
When I'm forced to by the popular opinion of co-workers or management by fiat. That is the most likely scenario.
There are some specific situations in which I would choose Subversion or Perforce over Mercurial. Those have to do with very specific features. For example, the ability to treat random subdirectories as repositories in their own right can be useful in some situations. Perforce's ability to re-arrange directory structure on checkout can also be useful. Perforce also does a superb job of handling large binary objects as are used in game development and other kinds of media work, and neither Mercurial nor Git are currently particularly good at those things.
But in general, there is no other reason I would ever choose a non-distributed revision control system for myself. I find them immensely limiting and constraining. I've been disappointed with them ever since I learned what version control was. There is nothing from a pure workflow standpoint that can be accomplished with a centralized revision control system that cannot be accomplished with a distributed one.
Subversion是一个非常好的集中式版本控制系统。它很成熟，并且得到 Trac 等其他工具的良好支持。它的“每个快照一个版本”非常出色，“分支”只是一个“轻拷贝”。确实，在具有更“脆弱”语义（例如每个文件的版本号和它们自己的特性）的遗留版本控制的上下文中，Subversion 非常出色。 （我已经使用它很多年了。）
也就是说，我要转向 Mercurial。 （我会考虑 Git，但目前 Mercurial 在 Windows 上要成熟得多。）Tortoise-Hg 远不如 Tortoise-SVN 成熟。然而，Mercurial 和 Git 都是为了合并而构建的。而且，这是版本控制系统的根本问题。
有了 Mercurial，每个存储库都拥有一切。合并很简单。一个仓库本身就是一个“沙箱”，所以你不需要有“主干”和“分支”的“千里眼”，做其他分支前的规划。简而言之，分布式存储库是开发人员团队的工作方式，即使开发人员集中在命令结构中（滚动到“最终批准的主干”分支）。
简介： Subversion 是一个很棒的模型，但非常集中。它很成熟，拥有成熟的工具，并且与其他工具（如 Trac）成熟集成。 Mercurial（和 Git）是更好的模型，但提供与 Subversion 相同的“每个存储库单一版本快照”。这些工具（如 Tortoise-Hg）不太成熟（与 Trac 集成需要更多工作），并且在使用 Mercurial 时您的想法会略有不同（例如，同步的分布式存储库），这提供了一些优势，但您确实应该这样做以不同的方式思考问题（与使用 Subversion 时不同）。
我每天都使用。他们都很棒。当我们以更成熟的方式将 Mercurial 与 Trac 集成时，我将完全转向 Mercurial。 （不太成熟的 Tortoise-Hg 不如 Tortoise-Svn，但我可以忍受。）
完全迁移到仅 Mercurial 可能需要一段时间（比如一年或两年以上，因为 Trac 提供了更好的原生 Mercurial）一体化）。 Mercurial 和 Subversion 之间的导入/导出并不可怕。我们在现有的代码库中使用这两种方法：中央“主干”是 Subversion，本地更改在 Mercurial 中，最终签入回到 Subversion。有用。
如果您耦合其他工具，只需检查其与 Subversion 和 Mercurial 的接口即可。如果一切都一样，那就选择 Mercurial。否则，使用 Subversion 不会出错（我们专门使用 Subversion 是因为 Trac 的支持），而且在此基础上使用 Mercurial 也很好（我们这样做）。
最后，在您如何提出问题的背景下：
我会选择 Svn 而不是 Mercurial，因为：
Trac）比较成熟，我们使用
那些其他工具；
Tortoise-Svn）明显更多
比 Mercurial 前端成熟
（如乌龟汞）；
简单模型（例如，
单版本快照），以及
集中存储库是人们的方式
从历史角度考虑版本
控制（不同的想法是
分布式所需的
Git/Mercurial 模型）
“主干”和“树枝”，并且不
需要重要的工具支持
帮助那些痛苦的人
跨分支合并。
Subversion is a very good centralized version control system. It is mature, and well-supported by other tools like Trac. Its "one-version-per-snapshot" is outstanding, and a "branch" is merely a "light copy". Really, in the context of legacy version control with more "brittle" semantics (like version-numbers-per-file and their own idiosyncrasies), Subversion is outstanding. (I've used it for years.)
That said, I'm moving to Mercurial. (I'd consider Git, but Mercurial is far more mature on Windows at present.) Tortoise-Hg is not nearly as mature as is Tortoise-SVN. However, both Mercurial and Git are BUILT TO MERGE. And, that's the fundamental problem for version control systems.
With Mercurial, every repository has everything. Merges are simple. A repository is itself a "sandbox", so you don't need to have the "clairvoyance" of "Trunk" and "branches", and do other pre-branch planning. In short, distributed repositories is how teams of developers work, even if the developers are centralized in a command-structure (rolling to a "final approved Trunk" branch).
Summary: Subversion is a great model, but very centralized. It is mature, with mature tools, and mature integration with other tools (like Trac). Mercurial (and Git) are better models, but provide the same "single-version-per-repository-snapshot" as Subversion. The tools (like Tortoise-Hg) are less mature (integration with Trac is more work), and you'll think slightly differently when working with Mercurial (e.g., distributed repositories that are synchronized), which provides some advantages, but you should really think about the problem differently (than you did with Subversion).
I use both daily. They are both awesome. When we get the Mercurial integration with Trac in a more mature manner, I'd move to Mercurial completely. (The less-mature Tortoise-Hg is not as good as Tortoise-Svn, but I can live with it.)
The full migration to Mercurial-only may take a while (like over a year or two, as Trac provides better native Mercurial integration). The import/export between Mercurial and Subversion is not terrible. We use both in our existing code base: Central "trunk" is Subversion, and local changes are in Mercurial, with final check-in back to Subversion. It works.
If you couple to other tools, just check for its interface with Subversion and Mercurial. If all things are equal, go Mercurial. Otherwise, you can't go wrong with Subversion (we use Subversion specifically because of support by Trac), and it's fine to use Mercurial on top of that (we do).
Finally, in the context of how you framed your question:
I'd choose Svn over Mercurial because:
Trac) is more mature, and we use
those other tools;
Tortoise-Svn) is significantly more
mature than Mercurial front-ends
(like Tortoise-Hg);
simple model (e.g.,
single-version-snapshot), and the
centralized repository is how people
historically think about version
control (different thinking is
required for the distributed
Git/Mercurial model)
"trunk" and "branches", and do not
require significant tool support to
help with those painful
merges-across-branches.
一个词：TortoiseSVN。对我来说，TortoiseSVN 是任何 VCS 的所有 GUI 客户端的标准。尽管 SVN 在 DVCS 方面存在缺陷，但 TortoiseSVN 使使用 SVN 变得轻而易举。 TortoiseGit 相当不错，并且模仿了 TortoiseSVN，但 TortoiseHg 并不是那么好。
另一个原因是出色的系统管理员支持。 SVN 的工具已经非常成熟并且成熟。 Git 和 Hg 都还没有赶上。
您还可以在这里查看我的答案：哪个版本控制最适合我？
这也是一个非常相似的问题：https://stackoverflow.com /questions/2693045/mercurial-vs-subversion
One word: TortoiseSVN. To me, TortoiseSVN is standard of all GUI clients for any VCS. Despite SVN's shortcomings in fron of DVCS, TortoiseSVN makes using SVN a breeze. TortoiseGit is pretty good and models TortoiseSVN, but TortoiseHg is not so great.
Another reason is awesome sysadmin support. The tools are well developed and mature when it comes to SVN. Both Git and Hg are yet to catch up.
You can also look at my answer here: which version control is best suited for me?
Also this which is a very similar question: https://stackoverflow.com/questions/2693045/mercurial-vs-subversion
当 Mercurial 的优势不是您的优势时，您将使用或应用于您的情况。
When the advantages of Mercurial are not advantages you will use or apply to your situation.