关于SVN:如何说服公司转换其源代码管理

关于SVN:如何说服公司转换其源代码管理

How to convince a company to switch their Source Control

我目前的工作地点目前正在过渡中,新的所有权已被接管,事情最终变得标准化,并且正在执行适当的准则。

但是我们仍在使用VSS,除此以外,实际上没有任何其他理由使用它。 我们不使用Visual Studio或任何真正需要它的工具。

从长远来看,我可以提出的绝对最佳论据来帮助他们说服采用Subversion之类的方法将是更好的解决方案。


VSS完全依靠客户端来管理数据库。如果客户端在错误的时间通过网络写入过程中断开连接,则文件将被丢弃到服务器上。不只是小费,还包括所有历史。希望你有一个好的备份。我经历过了。这是个坏消息。

通过VPN或其他远程连接的VSS使用情况非常糟糕。它使用SMB传输数据,您必须检索文件及其所有增量才能获得提示。讨厌。

我已经看到VSS开始以1GB的数据运行。数据库错误等。MS(在FAQ或KB中的某个地方)表示2GB实际上是最大安全限制。没有良好的管理工具(客户端负责庇护),因此您实际上并不会收到任何警告。

具有服务器进程以提供某种级别的事务和完整性控制的任何事物都是一种出色的解决方案。


最好的论据必须是您希望他们切换到颠覆的原因。 :)

我对VSS完全一无所知,但想到的是"如果没有损坏就不要修复"。您必须向您的经理表明VSS已损坏,需要修复。如果您可以向管理层说明如何为他们省钱,那就更好了。


@亚当·戴维斯(Adam Davis):呃,实际上是亚当,VSS是一种可怕的源代码控制系统。它具有破坏历史和丢失数据的悠久历史。合并很糟糕,不能很好地处理多个开发人员,而且速度很慢。历史也很差。微软真的不再支持它,您会注意到他们从未将其用于内部开发,现在他们甚至不出售它以支持更现代的解决方案(VSTS)。简而言之,如果您必须在VSS和任何其他类型的源代码控制之间进行选择,请选择另一种方法。


只需回顾一下功能,良好的源代码控制即可:

  • 能够轻松查看谁对什么文件进行了操作,何时以及以什么顺序进行处理的日志
  • 保留所有内容的过去版本历史
  • 轻松返回并重现旧版本的文件的特定版本,以更轻松地重现旧版本中报告的错误
  • 可以检索已删除的代码,或删除不需要的更改,而不必担心在此过程中丢失数据

我以前写过关于VSS为什么不是一个好主意的文章。您也许可以从中获得一些信息。此外,本文和此文章还包含更多信息。

VSS 2005记录了6.0中的一些漏洞,但不是特别有说服力。同样的脑残基础仍然存在。


为什么要通过VSS进行颠覆?

  • 免费软件
  • 易于管理
  • "签到"是原子的!
  • 易于分支和合并
  • 持续开发(即VSS死胡同)
  • 更好的工具来跟踪更改和查看日志
  • 工具集和平台无关,但也与许多工具集成

我向经理提出了建议,这很容易卖掉。我发现它更容易使用,特别是对于分支(我们的项目在VSS中"共享和固定"花了5个小时,然后每个操作花费了额外的时间来完成!)。


基本的答案是,您必须证明切换满足业务需求。例如:

  • 较低的开发成本
  • 日程安排较短(#1的另一种阴影)
  • 更适合满足流程要求(例如软件要求的可追溯性或构建的可复制性等)。
  • 对这些事情进行论证还需要定量的考虑,而不仅仅是"我们将降低成本,因为这是正确的方法!"。

    需要注意的一件事是,开发人员很难说服自己,不先通过基本的业务过滤器就进行更改将是有益的。一旦发生这种情况,您最终会遇到对工具不满意并因感到管理层不听而倍感沮丧的开发人员。如果您无法核实上述情况之一,那么您将无从说服任何事物的管理(除非管理不称职,但这是另一个问题)。


    让他们到Google来解决" vss问题","寻找安全的腐败源",或者直接在Wiki页面上查看。这应该使他们相信,将业务的如此重要部分押在您身上并不是长期可行的事情。

    您的团队有多大? (即,我的意思是有多少成员,而不是您是否是躲躲闪闪的人)一旦您开始获得六个以上非常活跃的用户,VSS就会让您头疼。

    我严重怀疑Microsoft是否使用它(实际上,他们不使用自定义的Subversion或CVS变体吗?),您必须问自己-如果公司不吃自己的狗粮,为什么要吃呢?


    能够处理分支和分支是一个开始。

    尝试在使用vss的??同时使用subversion一段时间,您很可能会发现许多论点来说服老板。如果您不这样做,那么您的老板是对的,没有理由改行。


    互联网上到处都是关于VSS漏洞的写得很好的文章。我会将其收集为远离VSS的证据。找到VSS无法支持的关键要求(远程工作,对其他操作系统的支持,工具集成),然后使用它来解决问题。然后,您需要找到与组织要求非常匹配的源代码控制系统-您确定Subversion是该系统吗?设置您选择的系统的演示,并以此证明其价值。

    我在以前的雇主(首先是CVS,然后是SVN)上实施了此更改,虽然成功,但我们不得不在边缘进行大量构建,并依靠许多(有时是不可靠的)开源项目来获得我们需要的所有工具。事后看来,我应该考虑尝试评估专业工具,例如Perforce,Vault甚至Team System。经过评估,我可以对CVS / SVN是否值得其"免费"价格标签做出适当的价值判断。


    任何证明转换的文档都会降低成本。失败的是,彩色图形和图表。也许是PowerPoint演示文稿。


    除了其他答案中给出的技术要点之外,您可能还存在一些非技术原因,您应该准备对以下问题做出回应:

    您应该调查您的公司是否有针对开放源代码软件的任何形式的政策(或有误导性的担心)。 如果公司或其律师不了解哪些许可证"感染"了专有代码,哪些许可证没有"感染"专有技术的来龙去脉,以及您可以使用不影响专有代码的开源代码做什么,您将 让他们很难从专有工具转换为开源工具。 (而且您可能需要做更多的教育工作。)

    在争论从专有(例如VSS)到开源(例如Subversion)的转换时,您还需要做好准备以捍卫代码的质量,并且不需要任何有关代码的保修或其他合同权利。


    @Jason:VSS已损坏。

    我认为,促使人们改变VSS的最有效方法是指出源代码资产的重要性。冒险承担其完整性不是明智的业务选择。

    另外,您的程序员是此资产的创造者,使他们变得更容易生产意味着在您的源代码资产中拥有更多价值。关于软件的Joel经常谈论对他的程序员的投资如何对他的公司来说是一个巨大的胜利。

    此处的其他答案都描述了提出案情时可以指出的具体原因。


    即使它没有损坏,从VSS迁移也有潜在的好处。首先也是最简单的是,您不必购买新的VSS许可证。其次,VSS产品存在许多不足的示例(有些也为MS所承认)。 SVN的学习曲线至少与VSS一样低,并且如果您的开发人员对他们的源代码控制系统更满意,他们更有可能尽早且经常使用它。这将为您的公司减少很多风险,这是一个很好的好处。


    推荐阅读