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