已关闭8年。
我本周正在面试一家公司的职位，在那里我将是唯一的最初的developerplus支持我正在接替工作的应用程序。因为这样的职位在细节上变化很大，所以我计划提倡一些使工作可行的特定方法。
我正在考虑提出的一件事是倾向于将现有源代码从SourceSafe（当前驻留在其中）移到更好的版本控制产品（如Perforce）中。
我在SourceSafe上遇到过许多不良经验，导致了诸如永久性文件锁定和代码损坏之类的大量问题。独自一人，恐怕这些轶事听起来像是“我想改变它，因为我不喜欢它”。如果我要提起这个话题，我想准备一个灌篮大赛。
那么，将SourceSafe视为劣质产品的经验原因是什么？
也可以看看：
Any Real-Life Visual Source Safe Horror Stories
How do I convince my team to drop sourcesafe and move to SVN?
最佳答案
问题here列表很长（虽然从2002年开始承认，但是此后产品并没有真正改变）
编辑：这是链接中的文本，以防万一它消失了。页面获得CCA3许可。
Visual SourceSafe：Microsoft的源代码破坏系统
通过艾伦·德·斯梅特
版本控制系统有很多好的解决方案。
SourceSafe不是
其中之一。
我从2002年春季开始使用SourceSafe已有五年。它始终如一
令人不愉快的经历。新版本无法改善任何导入。
我希望劝阻您不要使用SourceSafe，
避免您遇到我的糟糕经历。
缺少功能
SourceSafe缺乏可用的分支支持
版本控制系统应提供强大的branching
支持。借助强大的分支支持，开发人员可以轻松地
对旧版本进行较小的修订，同时继续下一个版本
主要版本仍在继续。可以检查高度实验性的代码
进入分支机构，使其与主流开发分离
但要备份并提供给其他开发人员。
如果项目是“冻结的”，而里程碑或最终版本是
建成后，开发人员可以继续开发下一个
分支上的版本。 （或更常见的是，可以
为冻结而创建，而总体开发仍在继续
主枝。发布完成后，冻结的更改
分支可以合并回主分支。）SourceSafe的
分支支持无法有效地支持其中的任何一种。
借助强大的分支，修订控制系统必须
还提供强大的合并支持以调和不同
分支机构。至少，系统必须允许开发人员
检查两个分支之间的差异，将其修改为
创建合并的版本，如果满意，请签入。
SourceSafe的合并支持与检查紧密集成
从而难以检查差异并测试
建议合并，然后再将其检入到树中。有了这个弱者
级别的支持，很容易将无法正常运行的代码检入
版本控制系统。
无法安全扩展SourceSafe
应该可以轻松扩展您的修订控制
具有附加功能的系统。发出的能力
总结办理登机手续的电子邮件至关重要。当使用
小组，常规电子邮件消息，其中列出了已签入的文件以及
签入与他们相关的消息确实有助于使所有人
最新变化。您可能还想添加
过滤器以防止签入不符合某些条件的代码
要求（标准版权声明或未编译）。
SourceSafe几乎不支持此功能。虽然有可能，但每一个
客户端需要安装其他功能。如果
单个客户端没有扩展名，它将悄悄地失败
表现如预期。
（有关详细信息，请参阅
Visual SourceSafe 6.0 Automation。
检查“捕获SourceSafe事件？概述”部分。）您可以
pay evenmore以获得第三方解决方案，但这对
在根本破损的产品上投入更多的钱？
SourceSafe以静默方式将陈旧文件保留在本地系统上
在更新本地工作空间以匹配服务器时，文件
在服务器上删除的文件应带到您的
注意。 （或删除，因为可以检索到旧版本
从版本控制系统中删除。）
项目中使用的日期文件，通常会引起问题。
当标头过期时，我经常遇到此问题
文件错误地包含在我的项目中。 SourceSafe失败
删除过期文件或提供任何警告。
SourceSafe无法正确处理缓慢的网络和公共互联网
SourceSafe无法通过缓慢的网络连接使用。它的
在公共互联网上实际上无法使用。此外，
因为SourceSafe通过网络共享工作，如果您放置一个
互联网上的SourceSafe服务器，暴露出任何弱点
在您的服务器上向全世界共享文件。
当然，如果
您愿意为无效的修订投入更多的资金
控制系统，您可以buy a third partyproduct解决此问题。
使用SourceSafe很难管理第三方模块
开发人员使用第三方模块的情况并不少见
在您的项目中快速添加所需的功能。对于
例如，您可以使用Codejock Software's XtremeToolkit。检查这些第三方模块是很自然的
进入您的版本控制系统。这样，当您踏上
向后查看先前的修订，您可以获取
相同版本的支持库和第三方模块
当时用于构建代码的代码。
不幸的是，SourceSafe使跟踪第三方模块
非常困难。最初检查中的第一个版本
不难签入新版本需要良好的记忆力，
注意细节。要添加新版本，您首先需要递归
检查将模块取出的文件夹。现在删除
磁盘上的目录，并用新版本替换。报到
新版本。您现在需要识别任何文件或
新版本中添加的目录。右键点击
SourceSafe中的模块文件夹，并使用“显示差异”
递归地生成已添加文件的列表。注意
哪个目录保存已添加的文件以及哪个
目录已添加。现在关闭差异报告
（该报告是模式报告，阻止您在
可见）。像平常一样添加新目录
目录。要添加新文件，请访问每个目录
新文件，然后使用文件>添加文件添加它们。再次使用
“显示差异”命令以递归方式生成文件列表
已被删除。请注意这些文件并关闭
再次报告差异。现在，删除其中的每个文件
SourceSafe。
如果您实际上已经调整了第三方模块，则可以使用SourceSafe
在追踪差异方面并没有提供任何特殊帮助，
将它们合并到新版本中。
（为了进行比较，请签入新版本的第三方
使用CVS的模块，您将
只需运行命令“ cvs -q import -m'Xtreme的导入
Toolkit 1.9'xtremetoolkit Codejock XT_1_9“。就这样。如果
您已经对需要集成的模块进行了更改，
将使用“ cvs checkout -j XT_1_8 -j XT_1_9
xtremetoolkit”。这将为您提供本地的
合并的更改，您可以立即检查是否
满意的。））
查看和检索历史版本非常有用
慢
通常需要获得历史版本的
源代码。您可能需要较旧的版本才能调查
错误报告，或者当前代码有故障，您需要
获得功能版本。 SourceSafe支持此功能，但是
对于非平凡的项目来说非常慢。获得历史
版本，您首先需要生成整个历史记录
您感兴趣的项目。在具有数百个项目的项目中
文件和超过一年的历史记录，这很容易
超过五分钟（即使您将实际搜索限制为
最近48小时的更改）。生成此历史记录后，您
通过选择最后一次签入来指定要获取的版本
接受。此过程完成的速度很慢
阻止开发人员检查以前的版本，
大大削弱了修订控制系统的目的。
难以维护一个的多个本地副本
项目
在对项目副本进行大量更改时，您
可能会被要求对该项目进行一些小的更改。最多
这样做最有效，最安全的方法是获取另一份
进行更改的项目。 SourceSafe存在两个问题
在这样做。首先，SourceSafe仅识别单个副本
您系统上的项目。您需要移动
项目目录返回SourceSafe期望规范的位置
复制，否则您需要将SourceSafe的概念重置为
规范副本存在。无论使用哪种技术，都很容易
不小心将SourceSafe指向错误的项目，然后检查
文件版本错误。其次，SourceSafe的合并较弱
功能意味着如果您需要同时更改两个文件中的相同文件
该项目的副本，您需要非常小心
对一个项目的更改不会破坏另一个项目的更改。
安全
SourceSafe在大型项目上会降级
Microsoft建议您的数据库不要超过5 GB。
（来源：Microsoft Best Practices）
虽然这是一个大型数据库，但对于大型数据库而言，这并不是没有道理的
项目，特别是如果您签入大型二进制文件（例如
Microsoft Word文档）。
SourceSafe集成可能会使Visual Studio崩溃
系统失去连接时，SourceSafe可能会挂起或崩溃
到SourceSafe数据库。虽然这对视觉有刺激性
SourceSafe，当您使用Visual Studio时，这可能会导致您失去工作
使用SourceSafe集成。轻松管理SourceSafe
在Visual Studio中打开的项目足以向自己打开
风险。为了最小化这种风险（并加快ClassView的速度），我建议
您
followMicrosoft's directions on disabling SourceSafe integration。
SourceSafe依赖危险的文件共享
SourceSafe并不是真正作为服务器运行，而是作为一组
通过SMB共享的文件。结果，您要依靠每个
个别客户不要行为不端。一个单一的行为
计算机可以破坏数据库。文件共享中的问题
您的操作系统上的实施可能会损坏数据库。只需要只读的用户
访问修订控制系统需要对
服务器，增加了风险（Required Network Rights for the SourceSafe Directories）。
应该每周对SourceSafe进行扫描以检查是否存在损坏
当然，由于腐败风险很高，
Microsoft建议您运行分析诊断程序
每周。
（来源：Microsoft Best Practices）
在Analyze运行时，所有开发人员都在
lockedout of the system（我希望每个人都记得退出
首先使用SourceSafe！）。我对SourceSafe的体验表明
在Windows 2000下运行的2 GB系统需要几个
小时检查是否每周运行。
SourceSafe无法正确处理多个时区
如果您的团队在使用相同的SourceSafe存储库
在不同的时区，您可能会遇到问题。 （SeeMicrosoft's details on the time zone bug.）唯一的解决方案
Microsoft提供的是错误地设置时钟
计算机到一个时区，或购买第三方
产品。
相关地，如果有任何客户端，这是一个潜在的问题
使用SourceSafe的计算机无法同步时钟。
电脑之间几分钟的差异可能导致
来自SourceSafe的奇怪行为，它试图进行协调
似乎来自未来的信息。
SourceSafe损坏
您的版本控制系统必须是可信赖的。你是
将您的辛勤工作委托给版本控制系统。如果
您的数据已损坏，系统毫无价值。 SourceSafe的
基本设计假设客户始终值得信赖
功能正常，并且没有任何干扰
通信导致数据损坏。结果，SourceSafe是
脆弱且不可信。我曾在SourceSafe工作过
三个不同的工作。在每种情况下，最终SourceSafe
数据库已损坏。数据已损坏，工作已
迷路了，时间已经浪费在这个问题上了。说话
其他开发人员，我了解到我的经验不是
独特。
烦恼
诸如更改目录之类的次要操作会擦除整个目录
输出窗口的内容，使检查过去变得困难
动作。
将本地版本与远程存储库进行比较是
笨拙。您选择您对SourceSafe感兴趣的目录
并选择比较差异。结果报告是模式报告，
阻止您在检查
报告。
从SourceSafe获取最新版本的文件时，
每个在本地更改的文件都会弹出一个对话框，以确认
更新。对话框中更新操作完全停止
等待您的回应。如果您这样做特别烦人
获得最新版本，离开您的计算机一段时间，
然后返回发现SourceSafe仅完成了10％，
等待您的答复。您可以防止对话框
有几种返回方式，但这样做却没有
表示遇到任何此类文件。所以当你
返回完成的更新，您将不知道
SourceSafe遇到潜在的问题。 SourceSafe应该
在遇到输出窗口时记下这些文件，使其
易于在输出窗口中扫描要调查的文件。
结论
如果您正在考虑SourceSafe，请考虑其他事项。如果
您现在正在使用SourceSafe，请尽快迁移。
这里仅仅是少数。
如果您只是必须使用SourceSafe，请绝对花时间
看一下微软的listof bugs in Visual SourceSafe 6.0和listof fixed bugs in Visual SourceSafe 6.0，你知道该怎么做
期望。 （这些链接最初来自Microsoft's Bugs page。
如果您使用的是其他版本，则此页面可能会有用
SourceSafe或以上链接失败。）
关于version-control - 为什么Visual SourceSafe的观看效果如此差？ ，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/1224537/