整个上午都在尝试检查某些内容-我现在意识到我已经失去了几天的工作。

它发生在之前-显然是SourceSafe的常见事件。SourceSafe是否可以成功使用而没有问题，如果可以，如何使用？

我的观点很简单，请尽快迁移到其他地方。不需要花费很长时间（1-2周的WAG），无论迁移需要花费多长时间，很容易在成本上证明这一点对管理人员来说是合理的。少量的时间迁移就等于可靠的源代码控制，几乎没有丢失源代码的机会。如果您的老板对此表示怀疑，请在Google上进行快速搜索以查找“提供安全的恐怖故事”或类似内容。

最差 单片机。曾经

SCM中的所有错误都体现在VSS中。甚至StarTeam也比Source Safe更好。Source Safe是版本控制领域的Internet Explorer 1：完全被其他任何实现取代。

我如何使用它？

我完成工作的典型工作流程是

1. 签出项目
2. 锁定所有文件（以避免与打开地狱邪恶大门的任何公司合并）
3. 我工作了吗
4. 每天检查我的变化
5. 再次检查了所有内容，并修复了集成中的所有问题
6. 签回

与Subversion相比，以上内容是可笑的（除了检查您是否未破坏构建）。

对我团队的编程实践的限制

这些是团队必须遵循的规则，以使其对我们有效。你的旅费可能会改变。

1. 一个人只能编辑一个文件（如果他们去度假，Heaven会为您提供帮助）
2. 不要分支，这太难管理了
3. 永远不要尝试回到以前的版本

该怎么办？

Polarion有一套很好的工具，可以从Source Safe迁移到Subversion（SVN），这是大多数企业中用于开源版本控制的当前事实上的标准。Subversion确实遭受了要求服务器可用以允许签入的痛苦（与GIT或Mercurial不同，后者是为分布式脱机团队设计的）。

将您的源代码控制更改为SVN / Mercurial / Git，再也不要回头！

大约一年前，我们将其停用。

发生了好几次，我第二天早上才没有在前一天晚上签到的东西。我没有发现这很有趣，因为它看起来像是我还没有完成我的工作，可疑。由于我刚来公司，对我来说可能很危险。

我们他们开始使用TFS，从那以后一直运行平稳。

我的看法？

有更好的工具，它们更易于使用，使用更安全并且完全免费。为什么要麻烦使用它呢？

这是我们有很多选择的发展领域。大多数或全部都比VSS更好。

• 颠覆
• 水星
• 吉特
• 更多

在商业操作中使用SourceSafe就像通过烧钱来加热建筑物。

在2000年，我的八家开发公司可能由于VSS数据库每天两次平均损坏而损失了5-10％的生产力。之所以这么低，是因为我们要进行每小时备份。

自从VSS迁移到Perforce，svn和git之后，我再也没有损坏过SCM数据库。

我可能对此不满意，但是..

VSS有效地使您陷入困境，以至于您无法调和任何需要意识到的现实，即现在沉闷的仓库不是您的错。

拜托，永远不要使用它。

使用了多年-这是默认解决方案，因为它已经存在。它咬了我好几次了，但是惯性很难克服

然后我不得不通过VPN远程使用它，即使是很小的登机手续也像是在针孔里塞满一块砖头。手动查找已更改的文件，将其压缩，通过电子邮件发送，远程访问源Vault计算机，解压缩它们以及从源Vault计算机中检入代码的速度更快。

切换到Mercurial。我可以在一分钟内跨VPN克隆整个源代码。而且我不再担心分支。

永不回头。

真是可恶 但总比没有好。

我使用了很长时间（将近10年），而没有亲自遇到任何问题（包括在我正在工作的团队中，尽管我们的代码趋向于合理划分以避免冲突等）。

但是，当有合适的，可靠的开源替代品出现时，有太多关于数据丢失的故事无法继续使用。

编辑：从评论中，该消息似乎可以避免任何复杂的事情（分支，合并，冲突），并且您可能还不错。还有更多，您将进入危险的领域。

即使MS也不赞成使用TFS。

对于在Visual Studio 6或更高版本中工作的单独商店或很小的商店，它是合格的，总比没有好。我认为它的糟糕程度有很多夸张之处，但是仅在一次丢失有价值的工作的情况下，您才会对产品感到厌烦（这是有充分理由的）。VSS占有一席之地，我认为它至少鼓励了许多根本不使用SCM工具的开发人员养成这种习惯，但是像许多技术一样，它现在已经过时了。

使用3年后，由于那里存在所有更高级/合理的替代方案而向我的经理抱怨并不断抱怨，我从来没有真正遇到过VSS问题，但是我也没有任何选择。

我的看法是，这既糟透了，又是打击。

关于它的最烦人的部分不是糟糕的版本控制和令人困惑的分支功能，而是文件菜单上的列表框不允许您按向右箭头键进行扩展。

真的很痛苦。

我对VSS的看法？我拒绝了一些工作机会（薪水很高），因为他们要求“ VSS能力”。我敢肯定，这里还有其他几个人也做过同样的事情。

您不仅遭受潜在的源损坏问题（应该为管理人员更换它辩护），而且您还必须忍受笨拙的备份以及无法在不同工作流中以团队的形式有效工作。

找到另一个SCM（其他任何一个），然后查看分支和合并的难易程度。想想那些必须从VSS解决方案中复制文件并将它们保存在其他位置，而又回去修复“生产”代码上的错误的时候。

对于踢，只需安装GIT-将其指向您的VSS文件，看看GASP两位程序员在同一时间处理同一文件的不同部分是多么容易，然后让该软件智能地合并您的更改... SCM工具应该不仅仅是源备份。

我对VSS的看法？定期使用了很长时间（仍然旧地偶尔用于较旧的组件），但对于我们的团队来说已经太二十世纪了：

• 非常不可靠
• 无法使用的分支
• 版本支持非常差，您有标签，但是（就像分支一样）不是真的可用

我拥有以上所有内容：选择一种waaaaay更好的开源替代品（甚至是旧的CVS），或者，如果您的公司具有某种MSDN订阅，则选择TFS。

• 它的默认锁定正在拖慢开发人员的速度，而且没人想弄乱它的设置
• 它不能很好地与其他服务集成，例如项目管理Web应用程序
• 与我们计划的CI服务器配合使用效果不佳

2010年Team Foundation的新内容应该会有所帮助，并设法摆脱VSS的不良部分。但是从本质上讲，它仍然依赖VSS，这就是为什么我们转向SVN的原因。

编辑 -我知道TFS是全新的，但是在测试它时，我询问的多个开发人员对此感觉非常相似。我之所以说“核心”，是因为我记得看过TFS在我的解决方案中制作的文件，就像VSS制作的一样。从开发人员的角度来看，甚至可能不了解VSS或TFS或任何其他SCM背后的技术。抱歉给您带来任何混乱。

早在XENIX下，我对SCCS感到不知所措。在Visual Studio 6中，VSS的所有失败和问题都有其独特的优势。我仍然将其用于小型项目，并且不再使用任何版本的SCCS。

我不知道为什么每个人都想对VSS不好。VSS不是分布式的，而分布式版本控制是

1. 更好
2. 允许在实践中进行非分布式版本控制

请阅读此。