我已经使用Subversion很多年了,在使用SourceSafe之后,我爱上了Subversion。结合TortoiseSVN,我真的无法想象它还能有什么更好的。
然而,越来越多的开发人员声称Subversion存在问题,我们应该转向新的分布式版本控制系统,比如Git。
Git如何改进Subversion?
我已经使用Subversion很多年了,在使用SourceSafe之后,我爱上了Subversion。结合TortoiseSVN,我真的无法想象它还能有什么更好的。
然而,越来越多的开发人员声称Subversion存在问题,我们应该转向新的分布式版本控制系统,比如Git。
Git如何改进Subversion?
当前回答
它是分布的。基准测试表明,它的速度要快得多(考虑到它的分布式性质,像diffs和log这样的操作都是本地的,所以在这种情况下,它当然要快得多),而且工作文件夹也更小(这仍然让我大吃一惊)。
当您使用subversion或任何其他客户端/服务器版本控制系统时,您实际上是通过签出版本在您的机器上创建工作副本。这代表了存储库外观的时间快照。通过更新更新工作副本,通过提交更新存储库。
使用分布式版本控制,您没有快照,而是拥有整个代码库。想要一个3个月大的版本吗?没问题,3个月前的版本还在你的电脑上。这不仅意味着速度更快,而且如果您与中央服务器断开连接,您仍然可以执行许多您习惯的操作。换句话说,您不仅拥有给定修订的快照,而且拥有整个代码库。
您可能认为Git会占用大量硬盘空间,但从我看到的几个基准测试来看,它实际上占用的空间更少。不要问我怎么做。我的意思是,它是由莱纳斯构建的,我猜他对文件系统略知一二。
其他回答
首先,并发版本控制似乎是一个很容易解决的问题。一点也不。无论如何……
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).
http://subversion.wandisco.com/component/content/article/1/40.html
我认为可以很有把握地说,在开发人员中,SVN和Git的争论已经激烈了一段时间,每个人都有自己的观点,哪个更好。这甚至在我们2010年及以后关于颠覆的网络研讨会的问题中被提出。
我们的开源和Subversion公司总统总监Hyrum Wright谈到了Subversion和Git之间的区别,以及其他分布式版本控制系统(DVCS)。
他还谈到了Subversion中即将发生的变化,比如下一代工作拷贝(WC-NG),他认为这会导致许多Git用户转换回Subversion。
请观看他的视频,并通过在这个博客上评论或在我们的论坛上发帖来告诉我们你的想法。注册很简单,只需要一点时间!
我喜欢Git,因为它实际上有助于在中大型团队中开发人员之间的沟通。作为一个分布式版本控制系统,通过它的推送/拉系统,它帮助开发人员创建一个源代码生态系统,这有助于管理在单个项目上工作的大量开发人员。
例如,假设你信任5个开发人员,并且只从他们的存储库中提取代码。每个开发人员都有自己的信任网络,从那里提取代码。因此,开发是基于开发人员之间的信任结构,其中代码责任由开发社区共享。
当然,在这里的其他答案中也提到了其他好处。
这一切都是关于做某事所需的易用性/步骤。
如果我在我的PC/笔记本电脑上开发一个项目,git会更好,因为它的设置和使用要容易得多。 合并时不需要服务器,也不需要一直输入存储库URL's in。
如果只有两个人,我会说git也更简单,因为你可以互相推拉。
一旦你超越了这一点,我就会选择颠覆,因为在这一点上你需要设置一个“专用”服务器或位置。
使用git可以像使用SVN一样做到这一点,但是git的好处被需要执行额外步骤来与中央服务器同步所抵消。在SVN中,你只需要提交。在git中,你必须先执行git commit,然后再执行git push。额外的步骤很烦人,因为你最后做了太多。
SVN也有更好的GUI工具的好处,但是git生态系统似乎正在迅速追赶,所以从长远来看我并不担心这一点。
这里所有的答案都是意料之中的,以程序员为中心,但是如果你的公司在源代码之外使用修订控制会发生什么呢?有很多文档不是源代码,它们受益于版本控制,应该与代码接近,而不是在另一个CMS中。大多数程序员都不是孤立地工作——我们作为团队的一部分为公司工作。
考虑到这一点,比较Subversion和git在客户端工具和培训方面的易用性。我看不出有哪一种分布式修订控制系统会更容易使用或向非程序员解释。我很乐意被证明是错误的,因为这样我就可以评估git,并希望它能够被那些需要版本控制的人(而不是程序员)接受。
即便如此,如果管理层问我为什么我们应该从集中式版本控制系统转向分布式版本控制系统,我也很难给出一个诚实的答案,因为我们不需要它。
Disclaimer: I became interested in Subversion early on (around v0.29) so obviously I'm biased, but the companies I've worked for since that time are benefiting from my enthusiasm because I've encouraged and supported its use. I suspect this is how it happens with most software companies. With so many programmers jumping on the git bandwagon, I wonder how many companies are going to miss out on the benefits of using version control outside of source code? Even if you have separate systems for different teams, you're missing out on some of the benefits, such as (unified) issue tracking integration, whilst increasing maintenance, hardware and training requirements.