我目前的工作地点正在过渡，新的所有权已经接管，事情终于变得标准化，并且正在执行适当的指导方针。
但我们仍在使用 VSS，实际上没有任何理由使用它，因为这就是最初设置的内容。我们不使用 Visual Studio 或任何真正需要它的工具。
从长远来看，我能提出什么绝对最好的论点来帮助说服他们使用像 Subversion 这样的东西会是一个更好的解决方案。
【问题讨论】：
标签： svn version-control visual-sourcesafe
VSS 完全依赖客户端来管理数据库。如果客户端在错误的时间通过网络在写入过程中断开连接，则您的文件将在服务器上被丢弃。不仅是小费，还有所有的历史。希望你有一个好的备份。我经历过。这是个坏消息。
通过 VPN 或其他远程连接使用 VSS 非常糟糕。它使用 SMB 传输数据，您必须检索文件及其所有增量才能获得提示。讨厌。
我已经看到 VSS 在 1GB 数据时开始运行。数据库错误等 MS（在 FAQ 或 KB 中的某处）说 2GB 确实是最大安全限制。没有好的管理工具（客户运行庇护），所以你不会真正得到任何警告。
任何具有服务器进程以提供某种级别的事务和完整性控制的东西都是一种出色的解决方案。
【讨论】：
最好的论据必须是您希望他们切换到颠覆的原因。 :)
我对 VSS 一无所知，但我想到了“如果它没有损坏就不要修复它”这句话。您必须向您的经理表明 VSS 已损坏并需要修复。如果您能向管理层展示如何为他们省钱，那就更好了。
【讨论】：
@Adam Davis: 呃，其实 Adam，VSS 是一个可怕的源代码控制系统。它具有破坏历史和丢失数据的悠久历史。合并很糟糕，不能很好地处理多个开发人员，而且速度很慢。历史也很差。 Microsoft 不再真正支持它，您会注意到他们从未将它用于自己的内部开发，现在他们甚至不出售它以支持更现代的解决方案 (VSTS)。简而言之，如果您必须在 VSS 和任何其他类型的源代码管理之间进行选择，请选择替代方案。
【讨论】：
只需回顾良好的源代码控制带来的功能：
【讨论】：
任何证明转换的文件都会降低成本。做不到这一点，多色图形和图表。也许是一个简报。
【讨论】：
互联网上充斥着关于 VSS 缺陷的优秀文章。我会收集这些作为远离 VSS 的证据。找到 VSS 无法支持的关键要求（远程工作、支持其他操作系统、工具集成）并使用它来解决您的问题。然后，您需要找到一个非常适合您组织要求的源代码控制系统——您确定 Subversion 是那个系统吗？设置您选择的系统的演示，并用它来证明它的价值。
我在前任雇主处实施了这一改变（先是 CVS，然后是 SVN），虽然它成功了，但我们不得不在边缘构建很多位并依赖很多（有时不可靠的）开源项目来获得我们需要的所有工具。事后看来，我应该考虑尝试评估专业工具，例如 Perforce、Vault 甚至 Team System。在评估了这些之后，我可以对 CVS/SVN 是否值得他们的“免费”价格标签做出正确的价值判断。
【讨论】：
能够处理分支和分叉是一个开始。
尝试与 vss 并行使用 subversion 一段时间，您很可能会发现许多论据来说服您的老板。如果你不这样做，你的老板是对的，没有理由切换。
【讨论】：
让他们到谷歌搜索“vss 问题”、“源安全损坏”或直接查看 Wiki 页面。这应该让他们相信，将如此重要的业务投注在您的业务上可能不是一件长期可行的事情。
您的团队有多大？ （即，我的意思是有多少成员，而不是你是否是沙拉道奇）一旦你开始获得超过六个相当活跃的用户，VSS 会让你头疼。
我严重怀疑微软是否使用它（事实上，他们不使用定制的 Subversion 或 CVS 变体吗？）你必须问自己 - 如果公司不吃他们自己的狗粮，你为什么要吃吗？
【讨论】：
基本答案是，您必须证明切换符合业务需求。例如：
在这些事情上提出理由还需要一些量化的东西，而不仅仅是“我们将降低成本，因为这是正确的方法！”。
需要注意的一点是，开发人员很容易让自己相信在不首先通过基本业务过滤器的情况下进行更改是有益的。一旦发生这种情况，您最终会遇到对他们的工具不满意并且倍感沮丧的开发人员，因为他们认为管理层不会倾听。如果您无法检查上述任何一项，那么您将没有机会说服任何事情的管理层（除非管理层无能，但这是另一个问题）。
【讨论】：
为什么要颠覆 VSS？
我向我的经理提出了建议，这很容易卖出。我发现它更容易使用，尤其是对于分支（我们的项目花了 5 个小时在 VSS 中“共享和固定”，然后每个操作都需要额外的时间来完成！）。
【讨论】：
我已经 previously written 关于为什么 VSS 不是一个好主意。您也许可以从中获得一些信息。 this article 和 this one 还包含更多信息。
VSS 2005 已经掩盖了 6.0 中的一些漏洞，但并没有以特别令人信服的方式。仍然存在相同的脑死亡基础。
【讨论】：
即使它没有损坏，从 VSS 迁移也有潜在的好处。首先，最重要的是，您不必购买新的 VSS 许可证。其次，VSS 产品存在许多缺陷的例子（一些也被 MS 承认）。 SVN 的学习曲线至少与 VSS 一样低，如果您的开发人员对他们的源代码控制系统更满意，他们更有可能尽早并经常使用它。这将为您的公司带来更少的风险，这是一个很好的好处。
【讨论】：
@Jason：VSS 坏了。
我认为促使改变远离 VSS 的最有效方法是指出您的源代码是多么重要的资产。以诚信冒险并不是明智的商业选择。
补充一点，您的程序员是该资产的创造者，让他们更容易提高生产力意味着您的源代码资产具有更多价值。 Joel on Software 经常谈到对他的程序员进行投资对他的公司来说是一个巨大的胜利。
这里的其他答案都描述了您在提出案件时可以指出的具体原因。
【讨论】：
除了其他答案中给出的技术点外，可能还有一些非技术性的原因潜伏着你应该准备好回应：
您应该调查贵公司是否有任何形式的政策来反对（或被误导为害怕）开源软件。如果公司或其律师不了解哪些许可证“感染”专有代码以及哪些许可证不感染专有代码的来龙去脉，以及您可以使用不影响您的专有代码的开源代码做什么，您将很难让他们从专有工具切换到开源工具。 （而且你手头上可能有更大的教育工作。）
在争论从专有（例如 VSS）到开源（例如颠覆）的转换时，您还需要准备好捍卫代码的质量，并且不需要任何担保或其他合同权利代码。
【讨论】：