为什么要使用SVN？有没有隐藏的专业人士（在 GIT/Mercurial/Bazaar 上）？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/3215282/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Why to use SVN? Any hidden pros (over GIT/Mercurial/Bazaar) there?
提问by Ivan
Possible Duplicates:
Why is git better than Subversion?
可能的重复：
为什么 git 比 Subversion 好？
I've already read a lot (not enough to get the perfect picture though) about versioning systems, and the obvious conclusion is that GIT is simply the best. Or Bazaar maybe. Or Mercurial. But if so it was, then nobody would be using SVN, but they still do. Why? I myself have no own opinion on what v.c.s. is generally the best yet because of lack of experience with them. Could you share your thoughts?
我已经阅读了很多关于版本控制系统的书（虽然还不足以获得完美的画面），但显而易见的结论是 GIT 是最好的。或者 Bazaar 也许。或水银。但如果是这样，那么没有人会使用 SVN，但他们仍然会使用。为什么？由于缺乏使用它们的经验，我自己对 vcs 通常是最好的没有自己的看法。你能分享一下你的想法吗？
回答by Zed
I'm currently maintaining a version control service for a U.S. research institution. We're not only supporting SVN in addition to Git and Mercurial, but also CVS.
我目前正在为一家美国研究机构维护一个版本控制服务。除了 Git 和 Mercurial，我们不仅支持 SVN，还支持 CVS。
SVN's "killer feature" among our users is narrow clones. You can make a checkout of just one subdirectory deep in a heirarchy, download only the files related to that directory, and still be able to make commits. Git very recently gave a similar, but not quite as useful variation on this feature called sparse checkouts (see also Sparse checkout in Git 1.7.0?). This lets you filter your working tree, but still forces you to download the entire history of the entire project, which can be prohibitive even when large binaries aren'tinvolved. Mind you, disk is cheap, and if you absorb the hit of the initial clone in advance subsequent pulls are quick enough, but this doesn't help people that went on a trip before they realized they needed to clone, and in any case even Git's sparse checkouts won't let you start your working tree five levels down, so it looks a bit ugly.
SVN 在我们用户中的“杀手级功能”是窄克隆。您可以只检出层次结构深处的一个子目录，仅下载与该目录相关的文件，并且仍然能够进行提交。Git 最近提供了一个类似但不太有用的变体，称为稀疏结帐（另请参阅Git 1.7.0 中的稀疏结帐？）。这使您可以过滤工作树，但仍会强制您下载整个项目的整个历史记录，即使没有大型二进制文件，这也可能令人望而却步涉及。请注意，磁盘很便宜，如果您提前吸收初始克隆的命中，随后的拉动就足够快了，但这并不能帮助那些在意识到需要克隆之前旅行的人，无论如何甚至Git 的稀疏检出不会让您开始向下五个级别的工作树，因此它看起来有点难看。
In addition, users find authzfiles easier to write than Git commit hooks, are more comfortable with the SVN syntax and methodology than any DVCS, and perhaps most importantly of all, already have many thousands of commits worth of history in SVN. Experiments in migrating large Subversion repositories to Git or Mercurial have provided mixed results, and these are scientists trying to get work done on their own projects, not donating their time to development of a DVCS.
此外，用户发现authz文件比 Git 提交钩子更容易编写，比任何 DVCS 更熟悉 SVN 语法和方法，也许最重要的是，在 SVN 中已经有数千次提交的历史价值。将大型 Subversion 存储库迁移到 Git 或 Mercurial 的实验提供了好坏参半的结果，这些科学家试图在自己的项目上完成工作，而不是将时间用于开发 DVCS。
CVS still has a following for a similar reason. Imagine, as a Git user, having sparse checkouts that also allow you to arbitrarily remap where files in the branch show up in your working tree, using a format that is versioned along with the repository and is distributed with every usual pull, that allows you to write definitions that can have groups that can include other groups, and that only pulls down the files necessary for filesystem placement on a clone. That's straightforward in CVS modules, and impossible in every DVCS. For all the sins of CVS (and believe me, we're quite aware of them, and go out of our way to discourage new CVS projects unless they absolutely can't live without modules), it's impossible to convince a group using that feature to migrate to another version control system.
出于类似的原因，CVS 仍然有追随者。想象一下，作为 Git 用户，拥有稀疏检出，还允许您任意重新映射分支中的文件在您的工作树中显示的位置，使用与存储库一起版本化并随每个常规拉取分发的格式，这允许您编写可以包含可以包含其他组的组的定义，并且只提取在克隆上放置文件系统所需的文件。这在 CVS 模块中很简单，在每个 DVCS 中都是不可能的。对于 CVS 的所有罪过（相信我，我们非常了解它们，并竭尽全力阻止新的 CVS 项目，除非它们绝对不能没有模块），说服使用该功能的团队是不可能的迁移到另一个版本控制系统。
DVCS software has brought some awesome innovations, but they're also missing things that some developers take for granted. Make sure you know in advance what your requirements are before choosing one.
DVCS 软件带来了一些很棒的创新，但它们也缺少一些开发人员认为理所当然的东西。在选择之前，请确保您事先知道您的要求是什么。
回答by detly
Talking about the company I work for — the biggest reason for using SVN is being able to keep huge, proprietary format, binary files under version control. Specifically, libraries of thousands of CAD files. In this instance, it doesmake sense to have the VCS be file-based like SVN is, rather than textual-information-based like Git.
谈到我工作的公司——使用 SVN 的最大原因是能够将庞大的、专有格式的二进制文件保持在版本控制之下。具体来说，包含数千个 CAD 文件的库。在这种情况下，它确实是有意义的有VCS是基于文件的，像SVN的，而不是文字信息为主如Git。
Putting aside whether or not you can do shallow "checkouts" with Git, or how well it stores binary data, the fact is that it's designedto track lines of textual information floating around a tree of source code. As well as it does this, that model is not suited to tracking libraries of binary data.
撇开您是否可以使用 Git 进行浅层“检查”，或者它存储二进制数据的程度如何，事实是它旨在跟踪围绕源代码树浮动的文本信息行。除了这样做之外，该模型也不适合跟踪二进制数据库。
Honestly though, that's about the only solid reason I would recommend it :P
老实说，这是我推荐它的唯一可靠原因：P
回答by sylvanaar
SVN is established and mature, with equally mature tooling.
SVN 已经建立并成熟，具有同样成熟的工具。
回答by sleepynate
Aside from the other things people are mentioning, (large quantities of binary data, mature, stable, etc) is that svn is built on a classic hierarchical model that is fundamentally different from patch/change-based revisions.
除了人们提到的其他事情（大量二进制数据、成熟、稳定等）之外，svn 是建立在经典的分层模型上的，该模型与基于补丁/更改的修订版有着根本的不同。
Our company made the decision to stay with SVN because this model fit the way that we handle our release cycle and branching. We see the direct progression of versions as a boon, not a bane. Updates are pushed to a centralized repository, and certain revisions considered "stable" are checked out to a live environment. At any time, it is instantly clear what the state of each environment is to all involved. (yes, this is possible with git.) Even the management who know nothing about revision control or software development can say: "We liked how you had it when it was at version 2547".
我们公司决定继续使用 SVN，因为这种模型适合我们处理发布周期和分支的方式。我们将版本的直接进展视为一种福音，而不是一种祸根。更新被推送到集中存储库，并且某些被认为“稳定”的修订被检出到实时环境中。任何时候，每个环境的状态对所有相关人员都是一目了然。（是的，这可以通过 git 实现。）即使是对版本控制或软件开发一无所知的管理人员也可以说：“我们喜欢它在 2547 版本时的样子”。
On the other hand, I should mention that I use darcs and git for projects that I and my friends and co-FOSS'ers work on together, as the distributed, patch-based model works for us. We can ad-hoc move through the timeline of the project and cherry-pick all kinds of changes.
另一方面，我应该提到，我将 darcs 和 git 用于我和我的朋友以及共同 FOSS 工作的项目，因为分布式、基于补丁的模型对我们有用。我们可以在项目的时间表中临时移动并挑选各种更改。
Really the advantage of SVN, my company, is its strong hierarchy and accessibility to non-programmers who are already familiar with concepts of "logging in" and "downloading".
我公司 SVN 的真正优势在于其强大的层次结构和对已经熟悉“登录”和“下载”概念的非程序员的可访问性。
回答by Greg Bacon
Subversion has an advantage when a repository contains lots of binary data, which don't delta-compress well. A Subversion checkout grabs the head only, but git clones the entire history, which can weigh in at multiple gigabytes. Yes, this is nice for airplane mode, but fetching the initial clone can take hours.
当存储库包含大量二进制数据时，Subversion 具有优势，这些数据不能很好地进行增量压缩。Subversion checkout 只获取头部信息，但 git 克隆了整个历史记录，其权重可达数 GB。是的，这对飞行模式很好，但获取初始克隆可能需要几个小时。
回答by Kenji Kina
People are still using Subversion because it's designed using the first paradigm to come for version control systems (centralized). Switching to distributed (and change-based instead of version-based) can take some time to get accustomed to (as you can see in Joel's experience), and so many teams decide not to use it due to resistance to change.
人们仍在使用 Subversion，因为它是使用第一个用于版本控制系统（集中式）的范式设计的。切换到分布式（基于变更而不是基于版本）可能需要一些时间来适应（正如您在Joel 的经验中所见），因此许多团队由于对变更的抵制而决定不使用它。
Mercurial tooling is quite mature, comparable to SVN in my opinion.
Mercurial 工具已经相当成熟了，在我看来可以与 SVN 相媲美。
回答by J. Polfer
While svn is established/mature, I have to admit, Kenji Kina is right: it's living in the past with a version control model that is outdated. I've only used svn, but after reading/watching Linus and Joel talk about DVCS, it sounds like a brilliant idea. I think Perforce does something similar.
虽然 svn 已经建立/成熟，但我不得不承认，Kenji Kina 是对的：它生活在过去，版本控制模型已经过时。我只使用过 svn，但在阅读/观看 Linus 和 Joel 谈论 DVCS 之后，这听起来像是一个绝妙的主意。我认为 Perforce 做了类似的事情。
This doesn't mean svn is bad (it works rather well!), but it is easier to manage your code and have more frequent commits with a DVCS. Because if you break something, its easy to undo. If you branch, its easy to merge. In general, they fixed a lot of the major headaches most have with Subversion.
这并不意味着 svn 不好（它运行得相当好！），但是使用 DVCS 更容易管理代码并且更频繁地提交。因为如果你弄坏了一些东西，很容易撤消。如果你分支，它很容易合并。总的来说，他们解决了很多 Subversion 最令人头疼的问题。
If you've never used another version control system before, and are cool with deploying it yourself, and write code (and not documents or pictures or things that you don't need textual stuff/diffing for), do yourself a favor and look into DVCS. Then you won't need to be re-educated.
如果您以前从未使用过其他版本控制系统，并且很擅长自己部署它并编写代码（而不是文档或图片或您不需要文本内容/差异的东西），请帮自己一个忙并看看进入 DVCS。那你就不需要再教育了。
