SubVersion最让我恼火的一点是它把自己的文件夹放在项目的每个目录中，而git只把一个文件夹放在根目录中。这不是什么大事，但这样的小事积少成多。

当然，SubVersion有Tortoise，它(通常)非常好。

http://subversion.wandisco.com/component/content/article/1/40.html

我认为可以很有把握地说，在开发人员中，SVN和Git的争论已经激烈了一段时间，每个人都有自己的观点，哪个更好。这甚至在我们2010年及以后关于颠覆的网络研讨会的问题中被提出。

我们的开源和Subversion公司总统总监Hyrum Wright谈到了Subversion和Git之间的区别，以及其他分布式版本控制系统(DVCS)。

他还谈到了Subversion中即将发生的变化，比如下一代工作拷贝(WC-NG)，他认为这会导致许多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.

对于那些正在寻找一个好的Git GUI的人来说，Syntevo SmartGit可能是一个很好的解决方案。它是私有的，但对非商业用途是免费的，可以在Windows/Mac/Linux上运行，我认为甚至可以使用某种git-svn网桥来支持SVN。

有趣的是: 我在Subversion Repos中托管项目，但是通过Git Clone命令访问它们。

请阅读在谷歌代码项目中使用Git进行开发

虽然谷歌代码原生说话 Subversion，可以轻松使用Git 在开发过程中。搜索“git” Svn建议这种做法是正确的 广泛传播，我们也鼓励你 用它来做实验。

在Svn存储库上使用Git给我带来了好处:

我可以分配到几个 机器，承诺和从 对他们来说 我有一个中央备份/公共svn存储库供其他人检查 他们可以自由地使用Git

“为什么Git比X好”概述了Git相对于其他scm的各种优缺点。

简要:

Git tracks content rather than files Branches are lightweight and merging is easy, and I mean really easy. It's distributed, basically every repository is a branch. It's much easier to develop concurrently and collaboratively than with Subversion, in my opinion. It also makes offline development possible. It doesn't impose any workflow, as seen on the above linked website, there are many workflows possible with Git. A Subversion-style workflow is easily mimicked. Git repositories are much smaller in file size than Subversion repositories. There's only one ".git" directory, as opposed to dozens of ".svn" repositories (note Subversion 1.7 and higher now uses a single directory like Git.) The staging area is awesome, it allows you to see the changes you will commit, commit partial changes and do various other stuff. Stashing is invaluable when you do "chaotic" development, or simply want to fix a bug while you're still working on something else (on a different branch). You can rewrite history, which is great for preparing patch sets and fixing your mistakes (before you publish the commits) … and a lot more.

有一些缺点:

There aren't many good GUIs for it yet. It's new and Subversion has been around for a lot longer, so this is natural as there are a few interfaces in development. Some good ones include TortoiseGit and GitHub for Mac. Partial checkouts/clones of repositories are not possible at the moment (I read that it's in development). However, there is submodule support. Git 1.7+ supports sparse checkouts. It might be harder to learn, even though I did not find this to be the case (about a year ago). Git has recently improved its interface and is quite user friendly.

在最简单的用法中，Subversion和Git是差不多的。两者之间没有太大区别:

svn checkout svn://foo.com/bar bar
cd bar
# edit
svn commit -m "foo"

and

git clone git@github.com:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push

Git真正的亮点在于分支和与其他人一起工作。