我的开发团队在非常基本的级别上使用源代码安全。我们正在进入一些更高级和更扩展的开发周期，我不禁认为，不使用分支和合并来管理变更将很快困扰我们。

我们认为哪些论点最有用，才能说服团队转向采用诸如SVN的更好解决方案？

我们使用什么程序来弥合功能差距，以使团队不会错过ide sourcesafe集成？

还是我应该只接受Sourcesafe并尝试将更好的做法纳入其中？

解决方案

如果我们使用VisualSVN，团队将不会错过VSS。能够同时处理一个文件的2个人也是一个大卖点。

首先，教他们如何有效地使用SourceSafe。

如果他们足够聪明，他们将开始喜欢使用版本控制系统的优势，如果这样，他们将很快达到SourceSafe的极限。在那儿，他们将能够听取意见，以便切换到更好的VCS，无论是CVCS还是DVCS，具体取决于团队准备实现的目标。

如果我们试图强迫他们以错误的方式使用SourceSafe时使用另一个VCS，例如保存源代码的zip文件(别笑，这就是他们两年前在我公司的行为)，那么他们将完全不愿意任何论点，尽其所能。

源安全性的不可靠性("请修复存储库...")对我们来说已经足够了。有趣的是(我从未测量过)SVN似乎总是更快。良好的并发检出/合并。

我一直认为对于开发人员来说这几乎是显而易见的。 SourceSafe似乎经常崩溃和死亡，以至于不想替换它。

我不记得任何SourceSafe用户曾经喜欢过该产品。同事真的喜欢吗？

在当前客户的使用情况下，CVS也有类似的问题。由于"它有效"并且他们大多对此感到满意，因此我无法推动他们进行改变。但是我每天都希望他们会的！

VS的AnkhSVN插件相当不错。有一些奇怪之处，但总体来说效果很好。

说服团队前进是一项艰苦的工作，我从未设法过：-(虽然我们有一个1GB的源数据库和多个用户，但速度VSS是s-l-o-w，这也许是更实际的争论之一。

编辑自从我使用VSS以来已经很久了，我忘记了它被锁定了！是的，如此处所述，如果我们拥有的开发人员不多，那么迁移到非独占/合并变更模型的能力应该会有所帮助。这样可以节省整个办公室的大喊"有人可以检查公用物品"！

无论我们做什么，都要慢慢移动！不要在第一天就开始与他们谈论分支-它只会推迟他们。我正在用该评论来刻板地描述VSS用户，但这就是我所看到的。

对于开发人员：出售它可以替代VSS，并且效果更好，更快。在第一天使用VisualSVN，这样他们的学习曲线就会变得很浅。以相同的方式出售它们，只是更快，更稳定，并且2个人可以编辑相同的文件，而且他们不会因某些人对一堆文件的锁定而生病。

对于管理员：出售它们比VSS更稳定，更易于管理。向他们展示VisualSVN服务器。

祝你好运！

我们曾经使用SourceSafe。然后，当我加入团队时，我在一个不同的位置，尽管我们拥有相当不错的LAN，但是当我尝试查看最新版本时却花了40分钟。我说服他们转换为CVS(我们现在使用SVN)，结帐时间减少到几分钟。 SourceSafe太慢了，无法在远程位置使用。

可靠性

• 大型数据库使SVN更加可靠
• 仍然积极支持SVN
• 原子提交-在VSS中，当另一个用户正在执行签入操作时获得最新版本时，我们将获得不一致的状态，从而迫使我们在更好的情况下重复"获取最新版本"，但是有时不幸的是，我们可能会留下一个代码库，编译但不起作用。由于原子提交，这在SVN中无法发生。

特征

• SVN分支/合并要好得多
• SVN内置了对远程访问的支持
• SVN更具可配置性(集成了外部Diff / Merge工具)
• SVN更可扩展(挂钩)

更高的生产率

• SVN"更新"比SS"获取最新版本"要快得多
• SVN命令行更简单，更简洁-这对于自动构建或者测试工具很有用

相同级别的IDE集成

• VSS直到最近都具有更好的VS集成，但是使用AnkhSVN 2.0不再是事实。

打开

SVN是开放的，并且有很多使用SVN或者与其合作的工具。一些示例包括：

• 与许多错误跟踪器或者产品周期管理产品集成
• 外壳整合
• 集成到各种产品中
• 各种管理和分析工具
• 资源可用，我们可以根据需要进行调整，解决问题(或者雇用某人为我们解决)

成本

• 我们无需支付任何许可或者维护费用

我们曾经使用VSS来销售管理和SVN团队的两个功能。

1)分支能力。使用VSS时，如果计划将某个发行版发布，则整个存储库将被锁定，直到该发行版实际发布为止。这包括测试和修复周期。因此，开发人员除了将修复版本发布到VSS存储库外，无法提交其他任何东西。这导致在每个发行版之后立即进行长时间的集成会议。通过在SVN中使用发布分支，不再需要锁定整个存储库。

2)能够立即回滚整个更改的能力。由于SVN在单个原子提交中记录了所有更改的文件，因此还原有问题的更改很简单。在VSS中，开发人员必须遍历整个存储库并找到几乎同时更改的每个文件，并将每个更改分别还原为每个文件。使用SVN，这与查找相关提交并单击TortoiseSVN中的"从此提交还原更改"按钮一样简单。

附带说明一下，我们使用TortoiseSVN，每个人都喜欢文件覆盖图标，可以查看已更改和未更改的内容。

我们从SourceSafe迁移到Source Gear Vault。对于某些习惯SourceSafe的人来说，此源代码控制引擎非常舒适。在几次关键时刻发生的SourceSafe腐败事件之后，我们最终决定做出更改。因此，我的建议是将销售演示重点放在SourceSafes的可靠性上。

没有人建议不再使用SourceSafe，甚至Microsoft也不要。他们现在将为我们提供(昂贵的)TFS许可证。 SourceSafe只是不可靠。

我在这里写过：E2上的Visual SourceSafe。这有点麻烦，但是那是因为我不得不使用SourceSafe相当长的时间，而且内存使我有些不高兴。

可靠性是会咬你的大狗。但是在SVN或者TFS中，我们可能还会喜欢一些功能：

TFS和SVN都具有多个文件的原子提交，但是如果我们"一次"检入两个文件，Sourcesafe不会，这不是一项操作，它与检入一个文件然后检入另一个相同。我们可以进入两者之间的状态，其中一个文件已签入，而另一文件则未签入。

SourceSafe不保留已删除文件，文件移动或者重命名的历史记录。

与初始印象相反，如果我们设置正确的选项，SourceSafe确实支持同一文件的多个同时检出。但是TFS(尤其是SVN)针对这种工作方式进行了更好的设计

与SourceSafe不同的是，TFS和SVN都可以很好地与Internet上的服务器配合使用(TFS可以，SVN很好)，而SVN可以很好地离线运行。如果我们在飞机上或者火车上有一台笔记本电脑，但没有网络，则仍可以工作并与以前的版本进行比较甚至还原，因为这样做的数据是本地保存的。

正如其他人指出的那样，SourceSafe与CVS一样，是"死"产品。它没有被积极开发。 TFS和SVN将来会推出新版本。

我们说："为了使团队转向采用更好的解决方案(例如SVN)，我们发现最有用的论点是什么？"

如果我们不知道这是一个更好的解决方案，那么为什么要提出争论呢？如果我们有足够的决心去寻求解决方案，那么我们应该知道那些原因已经存在。

是什么说服了我们应该向更好的方向发展？这些就是论点。那些论点之外的任何东西听起来都只是个人喜好问题。

告诉他们阅读此http://www.highprogrammer.com/alan/windev/sourcesafe.html

当然，使用源代码安全是要迁移到另一个源代码控制系统的充分理由吗？

我以前的工作是使用SVN和CVS，后来又搬到一家使用Source safe的公司(我们将迁移到SVN)，仅使用VSS就足以让我严重不喜欢它。尽管我以前工作的许多同事都告诉我有关VSS的恐怖故事，但我还是持开放态度，我认为自从使用VSS后，它会变得更好。

无法编辑文件，因为其他人正在/正在编辑它是荒谬的。我曾尝试使用更分布式的版本控制系统，如Bazzar，该系统由规范的制造，但是就可用工具而言，它还不够成熟。

源安全阻碍了SVN的开发，在此过程中，几乎每一个步骤都可以为我们提供帮助。

另外，使用乌龟Svn可使代码审查更加容易。

告诉他们将源代码当作钱来对待，然后将它们指向SourceSafe随处可见的众多示例。诸如此类的事情只是不应在适当的源代码控制系统中发生。

反对SourceSafe的最好论据是它只是不安全的，其他所有内容都可能被称为"我们不需要的功能"。

仅在一定程度上扩展，我们才可以放牧一堆猫。我去过两次，在这两种情况下，Source Safe都遇到了一些严重的问题，之后人们才见到光明。另一方面，作为一名经理，我只是指示团队使用SVN，而我们的生产率提高了300％(这是与印度和美国的团队合作的。我们以前需要很长时间才能完成svn的代码交换)

TortoiseSvn(免费)对于资源管理器集成非常有用，可以从上下文菜单中获得svn的所有功能。

VisualSvn(商业)使将svn集成到Visual Studio中变得一样容易，在解决方案浏览器中具有相同的状态指示，以及使用所有子版本化功能的上下文菜单。

这两个工具在使版本控制无缝化方面大有帮助。自从我处理VSS以来已经有很多年了，但是这些工具是使用源代码控制的一种更好的方法。

每个人都对VSS便便说的话同上

Subversion对分支和合并有很好的支持...我不记得VSS在这个部门完全没有任何功能。我确实记得团队需要从VSS释放时经历了一周的合并痛苦，而Subversion不再存在这种痛苦。

寻找一些借口开始在Ccode中使用非ASCII字符(中文和日文非常适合此操作)。

SourceSafe不喜欢Unicode(即使Visual Studio也不喜欢)，因此，如果我们选择正确的Unicode文本并签入和签出文件，则整个文件将显示为乱码。这样做的好处是，由于SS使用"差异"版本控制系统，因此实际上会将文件破坏到最初的签入版本，并且无法自动修复。

当这种情况仅发生一次时(就像在支持日语的应用程序上对我所做的那样)，我们可能会发现它是决定性的论点，赞成放弃SourceSafe。

首先在google中搜索描述VSS严重程度的页面数量，然后与同事分享。

其次，跳过颠覆，直接进入适当的分布式SCM，例如git或者mercurial。因为合并是分布式SCM的固有部分，所以它们必须比svn等集中式系统更好地处理合并。 Subversion仍在尝试对其自身进行改造，以更好地处理分支，在这种情况下，正确地构建了分布式系统。

首先，记录我们所遇到的所有问题，这些问题可以追溯到源代码管理系统中的根本原因。跟踪它们一个月左右。再加上由于不使用而错过的机会。 (如果我们说"不使用颠覆的机会成本"，我们可能会给MBA类经理留下深刻的印象)。这些数字实际上是机会成本的低估，因为如果我们不搞VSS，大概我们所做的工作可能会提供比小时计价价值更多的工作。

例如，我们是否遇到文件锁定的问题，需要多个人访问？
我们是否有部分(非原子)签到问题？
我们是否遇到困难，难以跟踪软件的发行版本并像过去那样重新创建存储库？
在将代码的副本复制到没有源安全客户端的服务器上时，我们是否遇到问题？
由于持续集成工具无法监视版本控制系统的更新，因此我们在构建和测试过程自动化方面是否存在问题？
我相信我们还会想到其他许多人。

如果我们可以算出由源安全和颠覆提供的事物的利益所引起的问题的大概时间/金钱成本(使用诸如$ 100 / hr的通用数字作为人工成本或者仅数小时)，以及延迟交付的项目的任何成本，则可以这样做。如果我们收集了一个月左右的数据，则可以使用每月颠覆来显示收益。

然后给出转换到颠覆的大概时间/成本。 (大约需要8个小时来设置和迁移代码，而每个开发人员需要2个小时来连接，检出和移动项目，类似的事情)风险很小，因为Sourcesafe仍然可以回滚。

如果成本大于每月收益，则可以将成本除以收益，以得出回收期。我们还应该在3年左右的时间里总计，以显示长期利益。再次强调一下，实际机会成本是无法直接计算的，因为在尝试管理Sourcesafe中的非分支发布时，我们可能一直在增加价值。

我建议我们继续进行操作，并开始在Sourcesafe用法中引入最佳实践，以期进一步转变为Subversion。希望这将使我们实际的Subversion迁移更加容易，并给我们时间来整理计划开发周期，分支策略等。适当地。

要考虑的另一件事是总体开发过程。源代码管理系统仅是解决方案的一部分，为了最大程度地利用Subversion或者任何其他产品，我们可能需要查看其用法与代码审查，质量保证和构建过程的相互作用。

Trac也会安装在Subversion的顶部。它是免费的，也是查看存储库的好方法(时间轴，Wiki等)

在进行这些争论时，请考虑是否需要解决公司可能对使用开放源代码工具所采取的任何政策。请参阅以下问题的答案：切换源代码控制

构建一些自动化功能，将VSS信息库镜像到SVN信息库

建立共识需要时间。如果VSS信息库的SVN镜像始终可用，则积累转换将更加容易。镜子不必是完美的，而必须是可用的。有用于此目的的现有工具。

对于我们来说，最关键的是VSS在VPN上的速度(即缺乏VSS)和道路上的低带宽酒店网络，以及试图通过防火墙建立隧道的问题，以便位于两个不同站点的两个团队可以快速，安全且可靠地工作。在相同的代码存储库中工作。我们正在运行两个VSS信息库，并打包了必须将其合并到另一个站点的信息库中以使它们保持同步的"交付"。

团队抱怨了一段时间，但很快就克服了。 TortoiseSVN本身就是很棒的工具，Visual Studio的AnkhSVN插件确实使每个人都可以轻松地进行转换。

回顾过去，我简直不敢相信有多少个"我们可以签入SoAndSo文件吗？"我们发送的电子邮件，更不用说" SourceSafe已关闭。我们必须还原存储库"电子邮件。

嘘。在阅读了此评论并写了此回复之后，我不敢相信我们会坚持这么久。

总结VSS问题的网页只是将人们指向该URL

让他们使用它，他们将切换到其他东西:)

现在，认真地说，告诉他们使用它并不难，许多我所知的开发人员拒绝切换，因为他们将subversion与unix和wierd命令相关联，向他们展示了TtheitroadtoiseSVN或者VisualSVN之类的界面，告诉他们Subversion允许他们无需像VSS那样强制锁定即可编辑同一文件。

最后但并非最不重要的一点是，它是开源的。它的成本比购买Team Foundation Server的成本低，并且如果我们四处看看，我们会发现小型开发人员团队可以很好地使用SVN。

我在一个小型开发团队中使用SourceSafe，并负责保持其运行。

我发现数据库很容易损坏，发生这种情况时没有太多资源。 "修复"功能(与大多数Microsoft修复功能一样)仅在98％的时间内不起作用。

自然，当我们的数据库损坏时，我们尝试从备份存档中还原。那是当我们发现SourceSafe的另一个坏处：它的2GB存档限制。在我们意识到无法恢复且无用的备份之前，我们已经在办公室进行了几个月的备份。

SourceSafe只是一场灾难，等待发生。

经过十多年的坚持，我计划在接下来的几周内放弃SourceSafe。通常，我是在一个小团队(少于5人)的环境中使用它的，而不必做很多分支工作，因为没有人要求这样做。

但是，对我而言，一直存在的＃1问题是，如果我们在网络驱动器上安装了SS数据库(大声笑，数据库；随机命名的文件的收集可以更准确地描述它)，那么该死的东西很容易损坏，在添加/签入操作的过程中，局域网连接发生某些情况，十分之九，我们将获得"无效的句柄"，并且该死的东西以某种方式被破坏，然后我们可以使用分析器工具来玩俄罗斯轮盘。

几个月前，我意识到，在过去的十年中，由于我不信任源代码控制系统，所以我一直在对每个正在开发的软件版本进行本地化的源代码压缩副本。真是浪费时间。

所以，这一切都在进行中。我可能会使用Subversion和TortoiseSVN，因为我认为团队将需要一个UI来简化过渡。

在我之前的工作中，我们从VSS开始，然后转移到SVN，再也没有回头。

刚开始新工作并且他们使用VSS，所幸的是，上述问题使他们开始考虑使用SVN。

由于有人将项目文件签出而无法将文件添加到项目中，这真是令人生气！

-李

当我在VS2005的发布会上，我设法让Microsofty陷入困境，并问为什么SourceSafe这么难使用。我得到的答复令人震惊，不仅是因为他说了什么，还因为他对他说的话非常了解。

他告诉我，这仅是供一个人使用的意思，即使那样做也不是很好。

我和我的同事们感到有些震惊，除了大声地笑，我们想不出其他办法，就像Microsofty一样！然后，他告诉我们内部未使用它。

因此，此后不久，我们切换到了Subversion。我们几乎决定在发布活动开始之前就这么做，但这只是确认我们做出了正确的决定。

如果将SourceSafe丢给另一个版本控制系统，我建议使用Mercurial而不是SVN

Joel Spolsky的书对Mercurial进行了很好的介绍，我们也可以将插件用于Visual Studio。

每当我由3人组成的团队工作时，他们就开始增加数字，进一步远离VSS似乎是很自然的一步。

同样，只要我向人们展示了持续集成的好处(特别是CruiseControl.NET)；本身通常足以保证从VSS迁移到SVN(我发现SVN与CruiseVSS一起使用CruiseControl.NET的效果要好得多)。

我建议在SVN中启动任何新项目，并在必要时在整个旧项目之间迁移，而不是一步一步地将其从另一个迁移到另一个。

我们会惊奇地发现VSS以这种方式死亡的速度有多快。