如何说服公司切换其源代码管理

Question

我目前的工作地点目前处于转型阶段，新的所有权已经接管，事情终于变得标准化，并且正在执行适当的指导方针。

但是我们仍然在使用VSS，除了最初设置之外，没有任何理由可以使用它。我们不使用Visual Studio，也不使用任何特别需要它的工具。

从长远来看，我能提出的绝对最好的论据是帮助说服他们从Subversion这样的东西会是一个更好的解决方案。

Answer 1

VSS完全依赖客户端来管理数据库。如果客户端在错误的时间通过网络写入中断连接，则您的文件将在服务器上被删除。不只是小费，而是历史。希望你有一个很好的备份。我经历过它。这是个坏消息。

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

我看到VSS开始采用1GB的数据。数据库错误等MS（在FAQ或KB中的某处）说2GB确实是最大安全限制。没有好的管理工具（客户运行庇护），所以你没有得到任何关于此的警告。

任何与服务器进程提供某种级别的事务和完整性控制是一个很好的解决方案。

Answer 2

最好的论据必须是你希望他们切换到subversion的原因。 ：）

我对VSS一无所知，但我想到的是“如果它没有破坏就不会修复它”这句话。您必须向您的经理证明VSS已损坏且需要修复。如果能向管理层展示如何为他们省钱，那就更好了。

Answer 3

@ Adam Davis：实际上是亚当，VSS是一个可怕的源控制系统。它历史悠久，腐败历史，数据丢失。合并很糟糕，不能很好地处理多个开发人员而且速度很慢。历史也很糟糕。微软并不再支持它，你会注意到他们从未将它用于自己的内部开发，现在他们甚至不推销它而采用更现代的解决方案（VSTS）。简而言之，如果您必须在VSS和任何其他类型的源代码控制之间进行选择，请选择替代方案。

Answer 4

通过浏览功能，良好的源代码控制带来：

• 能够轻松查看谁做了什么，何时以及以何种顺序执行哪些文件的日志
• 记录过去所有版本的历史
• 轻松返回并从任何以前的版本重现您文件的特定版本，以便更轻松地重现旧版本中报告的错误
• 能够检索已删除的代码，或删除不需要的更改，而不必担心流程中的数据丢失

Answer 5

任何证明转换的文件都会降低成本。失败了，多彩色的图形和图表。也许是一个权力点演示。

Answer 6

互联网上散落着关于VSS缺陷的精彩文章。我会收集这个作为远离VSS的证据。找到VSS无法支持的关键要求（远程工作，支持其他操作系统，工具集成）并使用它来解决您的问题。然后，您需要找到一个与您组织的要求非常匹配的源代码控制系统 - 您确定Subversion是该系统吗？设置所选系统的演示，并使用它来证明其价值。

我在之前的雇主（首先是CVS，然后是SVN）实现了这一变化，虽然它成功了但我们不得不围绕边缘构建大量的内容并依赖于大量（有时不可靠）的开源项目，以获得我们需要的所有工具。事后我应该考虑尝试评估专业工具，如Perforce，Vault甚至团队系统。在评估了这些之后，我可以对CVS / SVN是否值得他们的“免费”价格做出适当的价值判断。

Answer 7

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

尝试使用subversion与vss并行一段时间你很可能会发现很多参数来说服你的老板。如果你不这样做，你的老板是对的，没有理由改变。

Answer 8

让他们谷歌搜索“vss问题”，“源安全腐败”或者只是查看Wiki页面。这应该让他们相信，对你来说，投入如此重要的业务部分可能不是一件长期可行的事情。

你的团队有多大？ （也就是说，我的意思是有多少成员，而不是你是否是沙拉道夫）一旦你开始获得超过六个非常活跃的用户，VSS会让你头疼。

我严重怀疑微软是否使用它（事实上，他们不使用定制的Subversion或CVS变体吗？）你必须问自己 - 如果公司不吃自己的狗食，你为什么要这样做？吃吗？

Answer 9

基本答案是，您必须考虑到切换满足业务需求的情况。例如：

1. 降低开发成本
2. 更短的时间表（＃1的另一个阴影）
3. 更适合满足流程要求（如软件需求可追溯性或构建可重复性等）。

对这些事情进行说明也需要量化，而不仅仅是“我们会降低成本，因为这是正确的方式！”。

需要注意的一点是，开发人员很容易说服自己，如果不首先通过基本的业务过滤器进行更改将是有益的。一旦发生这种情况，您最终会遇到对他们的工具不满意的开发人员，并且因为他们认为管理层不会倾听而倍感沮丧。如果您无法检查上述事项之一，那么您将无法说服管理任何事情（除非管理层无能力，但这是另一个问题）。

Answer 10

为什么Subversion over VSS？

• 免费软件
• 易于管理
• “签到”是 atomic ！
• 易于分支和合并
• 持续发展（即VSS已死路）
• 用于跟踪更改和查看日志的更好工具
• 工具集和平台无关，但也集成了许多工具

我向我的经理提出了建议，这很容易卖。我发现它更容易使用，特别是对于分支（我们的项目花了5个小时在VSS中“共享和固定”，然后每个操作都需要额外的时间来完成！）。

Answer 11

我previously written关于为什么VSS不是个好主意。您可以从中获得一些信息。此外，this article和this one还包含更多信息。

VSS 2005已经在6.0中解决了一些问题，但并不是特别有说服力。同样的脑死亡基础仍然存在。

Answer 12

即使没有破坏，从VSS迁移也有潜在的好处。首先，最简单的是，您不必购买新的VSS许可证。其次，VSS产品存在许多不足的例子（有些也被MS承认）。 SVN的学习曲线至少与VSS一样低，如果您对源控制系统感到满意，他们更有可能提前和经常使用它。这将为您的公司带来更低的风险，这是一个很好的好处。

Answer 13

@Jason：VSS坏了。

我认为推动远离VSS变革的最有效方法是指出源代码对资产的重要程度。以诚信承担风险并不是明智的商业选择。

添加您的程序员是此资产的创建者，这使他们更容易提高工作效率意味着您的源代码资产更有价值。 Joel on Software经常谈到如何投资他的程序员是他公司的一大胜利。

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

Answer 14

除了其他答案中给出的技术要点之外，潜在的非技术性原因可能会让您准备回应：

您应该调查您的公司是否有任何针对（或误导）开源软件的政策。如果公司或其律师不了解哪些许可证“感染”了专有代码，哪些没有，以及您可以使用不影响您的专有代码的开源代码做什么，那么您将很难让他们从专有工具切换到开源工具。 （你可能手上有更大的教育工作。）

在争论从专有（例如VSS）转换到开源（例如颠覆）时，您还需要准备好捍卫代码的质量以及不需要保修或其他合同权利。代码。