我们能否最终转向企业软件中的DVCS?SVN仍然是发展的"必备"吗?

Con*_*ode 31 svn git version-control mercurial

Git/Mercurial越来越受欢迎.我看过很多文章比较SVN和Git/Mercurial,但我想知道是否真的有任何理由继续使用SVN.现在Git/Mercurial似乎有很多工具可以帮助推广其企业采用.

有没有理由继续使用SVN?Mercurial/Git终于为公司采用做好了准备吗?

Von*_*onC 101

一方面,SVN集成(包括IDE,框架,wiki,...)非常成熟,以及它的GUI和代码浏览器(即使像Git和Mercurial这样的DVCS每天都在进步).

另一方面,在企业环境中引入DVCS仍然不是一项简单的任务:


需要明确的是,使用DVCS可能是一个非常有效的选择:

  • 对于一个新项目,开发人员不依赖于传统工具或流程
  • 特别是当开发人员地理位置不在同一个地方时(通常是开源开发的情况,这就是DVCS主要用于那里的原因).

StackOverflow(不是一个开源项目)正在使用Mercurial(参见由Joel Spolsky编写的HgInit).
他们从SVN迁移到DVCS:

  • 部分是因为他们的开发人员现在遍布全世界(!)
  • 并且因为DVCS的合并设施比SVN更先进.
    (他们需要维护许多并行的略有不同版本的代码库,SO站点之间,StackExchange站点V1和V2,Area 51,...)
    请参阅" DVCS和CVCS之间的差异 ",或" Mercurial有什么好处"或者在svn上git进行分支/合并? "

  • 对于企业环境(我所在的地方),任何类型的任何转换都是微不足道的,因为它需要:

    • 资金(钱,即使工具是免费的)
    • 支持(这意味着拥有合适的人才)
    • 集成(使用现有的传统工具,GUI,IDE,如Visual Studio或许多其他工具,......)
    • 管理(在普通服务器方面,即使是DVCS)
    • 记录(特别是对于带有SVN背景的CVCS的用户)

因此,DVCS在企业环境中也非常有用:(
参见" Git的企业采用率? "或" 企业中基于Git的源代码控制:建议的工具和实践? ".)
(即使对于新项目)也是如此不像在较小的结构或开源环境中那样容易放置.

  • 在我的经验中,DVCS GUI是令人难以置信的*不成熟的.基本上SVN GUI现在处于OSX级别,而DVCS GUIS卡在Windows for Workgroups 3.11模式中......从真棒SVN GUI到DVCS领域所谓的艺术状态真的非常痛苦.如果你是一个命令行人,则不会发出问题,但对于像我这样的GUI wussies来说,这是非常痛苦的. (15认同)
  • +1是一个很好的答案与文档.:d (6认同)
  • 很棒的链接,他们实际上指出了如何克服人们[认为他们]需要坚持使用Subversion的大部分原因.链接文本在这方面有点令人困惑,但请查看每个链接文本以了解有关每个问题的更多信息. (4认同)
  • @Jeff:在IDE集成方面,[EGit](http://www.eclipse.org/egit/)将实现(Eclipse承诺:一年前所有项目都从CVS切换到Git),[Git]扩展名](http://code.google.com/p/gitextensions/)也更好(包括Visual Studio集成).[TortoiseGit](http://code.google.com/p/tortoisegit/)帮助前SVN用户进行类似Tortoise的shell集成.是的gitk和基于git-gui tcl-tk的工具很糟糕,但并不是唯一的选择.[Mac上的GitX](http://gitx.frim.nl)也不算太破旧. (3认同)

Thi*_*ilo 22

对于单个开发人员来说它被认为更好吗?

如果有的话,Subversion对于单个开发人员来说更糟糕(设置更麻烦).

但继续使用SVN的一个很好的理由是惯性.如果SVN适用于您的项目(或您的公司),则无需经历切换的痛苦.教导每个人新工具(和新的工作流程)可能需要一些培训费用,而没有任何实际的好处.

  • 我同意@Thilo.SVN没有任何严重的问题要求紧急切换.对于新项目,您可以选择git.否则,三年来我的comp正在使用SVN(r8000 +)并且全部都处于控制之中.我试着遵循"不要修复那些没有破坏的东西". (4认同)
  • 我几乎没有意识到切换到git(实际上是:使用git-svn网关)的"好处",直到我真的做到了.这是因为私有提交,可重写历史记录和补丁管理等新功能可以/应该完全改变您的工作流程,以及您组织工作的方式.智能手机与老式可靠诺基亚相比有哪些好处?如果您只对基本电话感兴趣,则无.如果您想改变工作方式,请加载. (3认同)
  • 没有冒犯,Thilo,但这听起来很像"在这里总是这样做......"这本身就不是一个好理由.我同意转换会有成本和痛苦,而且我也同意你不会毫不犹豫地做出改变(跳上潮流),但我也会说你不一定会说你是没有适当的成本效益分析,所有成本都没有实际效益.分布式版本控制有*真正的好处,真正的问题是那些好处足以超过成本吗? (2认同)
  • @Paul:最重要的是保持历史,保持关于究竟发布的内容,如何到达那里的"机构知识"等.拥有*a*版本控制系统(以及使用它的良好实践)至关重要为此,但使用哪一个...更小的项目.在考虑转向DVCS时,您必须弄清楚这样做的成本是否会在可容忍的时间范围内恢复; 如果需要20年才能恢复,几乎所有项目都不值得. (2认同)

Mhm*_*mmd 12

我认为Subversion仍然比Mercurial和Git更适用于媒体资产,Photoshop文件,After Effects复合等大型文件.我记得Linus Torvalds在本次Google Tech Talk中提到大文件是Git中为数不多的潜在问题之一.Mercurial有一些扩展用于在存储库外存储大文件.因此,在这种情况下,它们似乎都会遭受性能下降和/或其他问题.

另一方面,Subversion正在被当前的Blender Open Movie Project使用.我不认为他们使用它来存储渲染的帧,因为每个渲染通道至少会有几千兆字节的数据.但是,对于所有3D场景,对象,装备,纹理和脚本,它仍然是一个包含许多大文件的大型存储库.


JBi*_*rch 11

如果您长时间使用SVN ,我可以看到您可能继续使用SVN的原因.特别是在小公司或编码圈中,当你可能没有使用它们的任何更强大的功能时,从SVN到git或Mercurial的过渡可能会使你不利于进行切换.正如Thilo所指出的,一家使用SVN的大公司将会发现这一变化具有巨大意义.

此外,我认为SVN仍然存在,特别是在教学版本控制方面.但这取决于我自己在大学学习SVN的经验而不是自学git,所以我的观点不会是客观的.

话虽这么说,如果你从头开始创建一个存储库,我想不出你可能决定SVN是绝对必要的任何条件.也许在处理遗留系统时.

或遗留用户;)

  • +1"旧版用户" (8认同)
  • @Paul:虽然git-svn是一个很酷的小工具,但你并没有真正获得任何东西,并且必须做出一些权衡才能获得更多功能.我没有看到git-svn比SVN强大得多,而且它比git更具限制性.遗留基础设施保持不变,您现在可以使用git命令与其进行交互,但如果您已经在使用SVN并且它正在运行,那么您为什么要打扰复杂的问题呢? (3认同)

msw*_*msw 9

我不知道偏好集中式vcs 的任何内在原因,有很多外在因素,如遗留系统,管理惯性,学习曲线等.

DVCS几乎表明它是"更好的捕鼠器".

  • 用于隔离内在与外在的+1. (4认同)

Ada*_*ume 8

真正的问题不是SVN与Git/Mercurial,它是分布式的与集中式的.在某些情况下集中可以更好,例如需要严格控制和彻底记录的公司环境.

  • 你可以使用git作为集中版本控制系统(我们以这种方式使用它,但我们也利用额外的功能) (4认同)

Rud*_*udi 7

我们使用subversion作为数据的存储,这对于合并是非常简单的(我们进行硬件开发,而设计文件是未记录的二进制格式).SVN的优点是可以对文件设置锁定,因此只有一个开发人员可以处理文件,并且在编辑之前还必须检查最新的文件.


car*_*arl 6

当集中式范例理想时,Subversion是理想的选择.

其中一种情况是在论文上工作.保留每个人都可以使用的主副本更有意义.我们不想创建分支或标签.我们只想跟踪谁做出改变然后传播给所有作者.