来自SourceGear的Eric Sink写了一系列关于分布式和非分布式版本控制系统之间区别的文章。他比较了最流行的版本控制系统的优缺点。非常有趣的读物。 文章可以在他的博客www.ericsink.com上找到:

阅读差异 Git是版本控制工具中的C Git缺乏对不变性和DVCS最佳实践的尊重 DVCS和dag，第1部分 DVCS和dag，第2部分 DVCS和Bug跟踪 合并历史，dag和Darcs Git为什么这么快? Mercurial, Subversion和Wesley Snipes

Git还使分支和合并变得非常容易。Subversion 1.5刚刚添加了合并跟踪，但是Git仍然更好。使用Git进行分支是非常快速和廉价的。它使得为每个新特性创建分支更加可行。哦，与Subversion相比，Git存储库的存储空间非常有效。

我喜欢DVCS的主要原因是:

You can commit broken things. It doesn't matter because other peoples won't see them until you publish. Publish time is different of commit time. Because of this you can commit more often. You can merge complete functionnality. This functionnality will have its own branch. All commits of this branch will be related to this functionnality. You can do it with a CVCS however with DVCS its the default. You can search your history (find when a function changed ) You can undo a pull if someone screw up the main repository, you don't need to fix the errors. Just clear the merge. When you need a source control in any directory do : git init . and you can commit, undoing changes, etc... It's fast (even on Windows )

一个相对较大的项目的主要原因是由点3创建的改进的交流。其他的则是不错的奖金。

Windows中的Git现在得到了很好的支持。

查看GitExtensions = http://code.google.com/p/gitextensions/

以及更好的Windows Git体验的手册。

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

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.