我已经使用Subversion很多年了,在使用SourceSafe之后,我爱上了Subversion。结合TortoiseSVN,我真的无法想象它还能有什么更好的。
然而,越来越多的开发人员声称Subversion存在问题,我们应该转向新的分布式版本控制系统,比如Git。
Git如何改进Subversion?
我已经使用Subversion很多年了,在使用SourceSafe之后,我爱上了Subversion。结合TortoiseSVN,我真的无法想象它还能有什么更好的。
然而,越来越多的开发人员声称Subversion存在问题,我们应该转向新的分布式版本控制系统,比如Git。
Git如何改进Subversion?
当前回答
SubVersion最让我恼火的一点是它把自己的文件夹放在项目的每个目录中,而git只把一个文件夹放在根目录中。这不是什么大事,但这样的小事积少成多。
当然,SubVersion有Tortoise,它(通常)非常好。
其他回答
SubVersion最让我恼火的一点是它把自己的文件夹放在项目的每个目录中,而git只把一个文件夹放在根目录中。这不是什么大事,但这样的小事积少成多。
当然,SubVersion有Tortoise,它(通常)非常好。
使用Git,您几乎可以脱机做任何事情,因为每个人都有自己的存储库。
创建分支和合并分支非常简单。
即使你没有项目的提交权限,你仍然可以拥有自己的在线存储库,并发布补丁的“推送请求”。每个喜欢你的补丁的人都可以把它们拉到他们的项目中,包括官方的维护者。
分叉一个项目,修改它,并仍然从HEAD分支中合并错误修复是很简单的。
Git适用于Linux内核开发人员。这意味着它非常快(必须如此),并且可以扩展到数千个贡献者。Git使用的空间也更少(Mozilla存储库的空间最多减少30倍)。
Git非常灵活,非常TIMTOWTDI(有不止一种方法可以做到)。你可以使用任何你想要的工作流,Git会支持它。
最后,还有GitHub,一个托管Git存储库的好网站。
Git的缺点:
它更难学,因为Git有更多的概念和命令。 修订版不像subversion那样有版本号 许多Git命令是神秘的,错误消息对用户非常不友好 它缺少一个好的GUI(比如伟大的TortoiseSVN)
由于它不需要不断地与中央服务器通信,几乎每个命令都在不到一秒的时间内运行(显然git的push/pull/fetch较慢,因为它们必须初始化SSH连接)。分支要容易得多(一个简单的命令就可以分支,一个简单的命令就可以合并)
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.
为什么我认为Subversion比Git好(至少对于我所从事的项目来说),主要是因为它的可用性和更简单的工作流程:
http://www.databasesandlife.com/why-subversion-is-better-than-git/