我倾向于认为这里的大多数人认为 SVN 是镀金的好东西，而 VSS 是有史以来设计的最糟糕的程序（至少就版本控制而言）。
说了这么多，为什么呢？我使用了一些 CVS，而我目前的工作使用 VSS，从团队的角度来看，我真的无法分辨出那么大的区别。我看到的大多数差异都是外观上的。当然，我也没有尝试过任何分支/合并，但是作为一个进来的编码器，签出文件，处理这些文件并在一天结束时签入，为什么我想要 1其他？
Pulsehead
问问题
19137 次
13 回答
39
于 2008-11-20T19:05:04.487 回答
10
使 Visual Source Safe 的 Microsoft 不会在内部将它用于任何规模很大的项目。在我的书中，这是反对它的主要标志。将它用于大型项目，您就会明白为什么；它很慢，如果你决定让它自动合并任何东西，上帝会帮助你。
于 2008-11-20T18:29:59.113 回答
6
VSS 不是原子的，因此在另一个用户的大型签入期间获取最新信息将导致文件集不完整。如果在 WAN 上工作，由于 VSS 的设计是在共享上工作，这也会变得更糟。
于 2008-11-20T18:45:50.250 回答
5
我最后一家公司从 VSS 切换到 SVN 是因为
- 扩张。程序员的数量翻了一番，我们不想为额外的 VSS 许可证付出代价
- 错误。VSS 擅长维护文件的最新版本，但历史记录经常被破坏。
- 更多的错误。检查/恢复工具毫无用处，因为当数据库变得非常大时它们开始崩溃。
于 2008-11-20T18:30:35.600 回答
3
我知道选择 VSS 很容易，但重要的是要记住一些事情（暂时离开杂草！）
- 对于小型 Microsoft 开发团队，VSS 是一个非常易于实施的解决方案，其中的替代方案是无版本控制。
- VSS 没有成本，不需要服务器（文件共享除外）。
- 最低的常见恶魔。
- 它通常确实有效，并且许多商店都在使用它。
- 我宁愿选择 VSS，也不愿让它不存在。
你不必在所有这些点上都同意我的观点，我只是在证明它确实有它的位置，并且在不同的场景中具有价值。
于 2008-11-21T03:17:51.107 回答
1
VSS 有一段非常糟糕的历史，它必须克服。更新的版本似乎更稳定，但它仍然背负着大量的负面包袱。
于 2008-11-20T18:30:30.967 回答
1
您应该尽快从 VSS 运行。如果您过去没有遇到过问题，那么您应该得到一些。这就像俄罗斯轮盘赌的定时炸弹——你永远不知道它什么时候会爆炸。
SVN 是一个很棒的工具，非常易于设置和管理。用于备份或复制的管理工具非常好。
我会在任何时候推荐 SVN 而不是 VSS。
于 2008-11-20T19:18:39.590 回答
1
Visual Studio 中集成的旧论点不再适用。AnkhSVN 2.0提供了一个集成解决方案，VisualSVN将 TortoiseSVN 集成到 Visual Studio 中。
而TortoiseSVN本身就足以让许多用户有理由切换。
于 2008-11-21T14:44:22.203 回答
1
我在使用 Java 代码时遇到 VSS 问题。虽然是 getLatestVersion，但 VSS 无法处理 Java 中项目和包的嵌套结构。我得到了相同的 inifite 文件夹结构。SVN 在这方面相当简单。
于 2010-04-20T18:56:09.853 回答
0
就功能而言，CVS 和 VSS 几乎是一回事。因此，它们不是比较它们中的每一个的好起点。
但是，如果您只是将 SVN 和 VSS 用作团队的咕噜声，您可能永远不会看到它们之间的区别。您确实必须开始将它们用作项目经理才能真正看到差异，例如分支，合并等。
于 2008-11-20T18:31:49.483 回答
0
从开发人员的角度来看，SVN 运行良好，但它在整个目录树中存储配置信息的方式对于系统管理员来说是令人抓狂的（尤其是那些在开发人员拒绝执行提交/重新签出过程时将其移动到另一台服务器的人）。:) 所以，这不是所有的镀金善良！
于 2008-11-20T18:34:01.710 回答
0
我实际上认为 Perforce 是镀金的好东西。GUI 工具足够好，您可以将它们提供给设计师或艺术家，并让他们像我们开发人员一样使用源代码控制。我很确定 VSS File->Add Files 窗口早于 windows 95。使用中的文件被锁定的整个概念是荒谬的。几十年前我们不是用并发版本控制解决了这个问题吗？我经历过历史记录损坏（如果我错了，请纠正我）但 VSS 甚至不支持分支和合并。
于 2008-11-20T18:46:00.280 回答