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

但是我们仍在使用VSS，实际上没有任何其他理由使用它，而是最初设置的内容。我们不使用Visual Studio或者任何真正需要它的工具。

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

解决方案

回答

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

回答

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

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

回答

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

通过VPN或者其他远程连接的VSS使用情况非常糟糕。它使用SMB传输数据，我们必须检索文件及其所有增量，才能获取提示。可恶的。

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

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

回答

只需回顾一下功能，良好的源代码控制就可以带来：

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

回答

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

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

回答

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

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

回答

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

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

我严重怀疑Microsoft是否使用它(实际上，他们不使用定制的Subversion或者CVS变体吗？)，我们必须问自己公司是否不吃自己的狗粮，为什么要吃它？

回答

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

回答

基本的答案是，我们必须证明切换满足业务需求。例如：

• 较低的开发成本
• 日程安排较短(＃1的另一种阴影)
• 更适合满足流程要求(例如软件要求的可追溯性或者构建可重复性等)。

对这些事情进行论证还需要一些量化的方面，而不仅仅是"我们将降低成本，因为这是正确的方法！"。

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

回答

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

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

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

回答

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

回答

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

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

回答

@Jason：VSS坏了。

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

另外，程序员是此资产的创造者，使他们更容易提高生产效率意味着源代码资产具有更多价值。关于软件的Joel经常谈论对他的程序员的投资如何对其公司来说是一个巨大的胜利。

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

回答

除了其他答案中给出的技术要点之外，还有一些非技术性原因可能会导致我们应准备对以下问题做出回应：

我们应该调查公司是否针对开放源代码软件采取了任何形式的政策(或者误导了对开放源代码的恐惧)。如果公司或者其律师不了解哪些许可证会感染专有代码，哪些许可证不会感染专有代码的来龙去脉，以及我们可以使用不影响专有代码的开源代码做什么，那么我们将很难使他们转换从专有工具到开源工具。 (而且手头上可能还有更大的教育工作。)

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