我认为Subversion很好。直到你开始合并…或者做任何复杂的事情。或者做任何Subversion认为复杂的事情(比如查询哪些分支弄乱了特定的文件，更改实际上来自哪里，检测复制和粘贴，等等)…

我不同意获胜的答案，我认为GIT的主要好处是离线工作——它当然有用，但它更像是我的用例的额外功能。SVK也可以离线工作，对我来说，把我的学习时间投入到哪一个是没有问题的)。

只是它非常强大、快速，而且——在习惯了这些概念之后——非常有用(是的，在这个意义上:用户友好)。

有关合并故事的更多细节，请参见: 使用git-svn(或类似)*只是*帮助svn合并?

这一切都是关于做某事所需的易用性/步骤。

如果我在我的PC/笔记本电脑上开发一个项目，git会更好，因为它的设置和使用要容易得多。 合并时不需要服务器，也不需要一直输入存储库URL's in。

如果只有两个人，我会说git也更简单，因为你可以互相推拉。

一旦你超越了这一点，我就会选择颠覆，因为在这一点上你需要设置一个“专用”服务器或位置。

使用git可以像使用SVN一样做到这一点，但是git的好处被需要执行额外步骤来与中央服务器同步所抵消。在SVN中，你只需要提交。在git中，你必须先执行git commit，然后再执行git push。额外的步骤很烦人，因为你最后做了太多。

SVN也有更好的GUI工具的好处，但是git生态系统似乎正在迅速追赶，所以从长远来看我并不担心这一点。

This is the wrong question to be asking. It's all too easy to focus on git's warts and formulate an argument about why subversion is ostensibly better, at least for some use cases. The fact that git was originally designed as a low-level version control construction set and has a baroque linux-developer-oriented interface makes it easier for the holy wars to gain traction and perceived legitimacy. Git proponents bang the drum with millions of workflow advantages, which svn guys proclaim unnecessary. Pretty soon the whole debate is framed as centralized vs distributed, which serves the interests of the enterprise svn tool community. These companies, which typically put out the most convincing articles about subversion's superiority in the enterprise, are dependent on the perceived insecurity of git and the enterprise-readiness of svn for the long-term success of their products.

但问题是:Subversion是架构的死胡同。

Whereas you can take git and build a centralized subversion replacement quite easily, despite being around for more than twice as long svn has never been able to get even basic merge-tracking working anywhere near as well as it does in git. One basic reason for this is the design decision to make branches the same as directories. I don't know why they went this way originally, it certainly makes partial checkouts very simple. Unfortunately it also makes it impossible to track history properly. Now obviously you are supposed to use subversion repository layout conventions to separate branches from regular directories, and svn uses some heuristics to make things work for the daily use cases. But all this is just papering over a very poor and limiting low-level design decision. Being able to a do a repository-wise diff (rather than directory-wise diff) is basic and critical functionality for a version control system, and greatly simplifies the internals, making it possible to build smarter and useful features on top of it. You can see in the amount of effort that has been put into extending subversion, and yet how far behind it is from the current crop of modern VCSes in terms of fundamental operations like merge resolution.

现在，对于那些仍然相信Subversion在可预见的未来足够优秀的人，我有一个发自内心的不可知论的建议:

Subversion永远不会赶上从RCS和CVS的错误中吸取教训的新型vcs;这在技术上是不可能的，除非他们从头开始重新配置存储库模型，但这样就不是真正的SVN了，不是吗?不管你认为自己有多不具备现代VCS的能力，你的无知也无法保护你远离Subversion的陷阱，其中许多情况在其他系统中是不可能或很容易解决的。

It is extremely rare that the technical inferiority of a solution is so clear-cut as it is with svn, certainly I would never state such an opinion about win-vs-linux or emacs-vs-vi, but in this case it is so clearcut, and source control is such a fundamental tool in the developer's arsenal, that I feel it must be stated unequivocally. Regardless of the requirement to use svn for organizational reasons, I implore all svn users not to let their logical mind construct a false belief that more modern VCSes are only useful for large open-source projects. Regardless of the nature of your development work, if you are a programmer, you will be a more effective programmer if you learn how to use better-designed VCSes, whether it be Git, Mercurial, Darcs, or many others.

首先，并发版本控制似乎是一个很容易解决的问题。一点也不。无论如何……

SVN非常不直观。Git更糟糕。这可能是因为开发人员喜欢并发版本控制这样的难题，他们对制作一个好的UI没有多大兴趣。[/ sarcastic-speculation]

SVN supporters think they don't need a distributed version-control system. I thought that too. But now that we use Git exclusively, I'm a believer. Now version control works for me AND the team/project instead of just working for the project. When I need a branch, I branch. Sometimes it's a branch that has a corresponding branch on the server, and sometimes it does not. Not to mention all the other advantages that I'll have to go study up on (thanks in part to the arcane and absurd lack of UI that is a modern version control system).

Subversion仍然是一种更常用的版本控制系统，这意味着它有更好的工具支持。您会发现几乎所有IDE都有成熟的SVN插件，并且有很好的资源管理器扩展可用(如TurtoiseSVN)。除此之外，我不得不同意Michael的观点:Git并不比Subversion更好或更差，它是不同的。

其他的回答很好地解释了Git的核心特性(这些特性非常棒)。但是还有很多小方法可以让Git表现得更好，并帮助我的生活更加理智。以下是一些小细节:

Git has a 'clean' command. SVN desperately needs this command, considering how frequently it will dump extra files on your disk. Git has the 'bisect' command. It's nice. SVN creates .svn directories in every single folder (Git only creates one .git directory). Every script you write, and every grep you do, will need to be written to ignore these .svn directories. You also need an entire command ("svn export") just to get a sane copy of your files. In SVN, each file & folder can come from a different revision or branch. At first, it sounds nice to have this freedom. But what this actually means is that there is a million different ways for your local checkout to be completely screwed up. (for example, if "svn switch" fails halfway through, or if you enter a command wrong). And the worst part is: if you ever get into a situation where some of your files are coming from one place, and some of them from another, the "svn status" will tell you that everything is normal. You'll need to do "svn info" on each file/directory to discover how weird things are. If "git status" tells you that things are normal, then you can trust that things really are normal. You have to tell SVN whenever you move or delete something. Git will just figure it out. Ignore semantics are easier in Git. If you ignore a pattern (such as *.pyc), it will be ignored for all subdirectories. (But if you really want to ignore something for just one directory, you can). With SVN, it seems that there is no easy way to ignore a pattern across all subdirectories. Another item involving ignore files. Git makes it possible to have "private" ignore settings (using the file .git/info/exclude), which won't affect anyone else.