我如何说服我的团队放弃sourcesafe并转移到SVN？
我的开发团队在非常基础的层面上使用源码安全。 我们正在进入一些更高级和更广泛的开发周期，我不禁认为不使用分支和合并来pipe理变化将会很快被我们咬。
为了说服你的团队转向像SVN这样的更好的解决scheme，你认为哪些论点最有用？
你用什么程序来弥补function上的差距，这样团队就不会错过ideafeafe集成？
还是应该接受资源安全措施，并试图将更好的做法付诸实践？
首先，教他们如何高效地使用SourceSafe。
如果他们足够聪明，他们会开始喜欢使用版本控制系统的优势，如果这样的话，他们很快就会达到SourceSafe的极限。 这就是为什么他们能够更倾听你的观点，以便切换到更好的VCS，它可以是CVCS还是DVCS，取决于团队准备实现什么。
如果你试图强迫他们在使用SourceSafe的时候使用另一个VCS，比如保存源代码的zip文件（不要笑，那两年前他们是如何在我公司工作的），他们会完全不情愿的任何论证，尽可能好。
可靠性
- 对于大型数据库，SVN更可靠
- SVN仍然积极支持
- primefaces提交 – 当VSS获得最新版本，而另一个用户正在执行签入时，可能会出现不一致的状态，迫使您在更好的情况下重复“获取最新版本”，但有时如果运气不好，您可能会留下一个代码库编译但不起作用。 这在SVN中不会发生，这要归功于primefaces提交。
特征
- SVN分支/合并好得多
- SVN内置支持远程访问
- SVN更具可configuration性（集成了外部Diff / Merge工具）
- SVN更具可扩展性（钩子）
更好的生产力
- SVN“更新” 比SS “获取最新版本” 要快很多
- SVN命令行更容易和更清晰 – 这对自动化构build或testing工具很有用
同一级别的IDE集成
- 直到最近VSS才有更好的VS集成，但是随着AnkhSVN 2.0，这不再是事实。
打开
SVN是开放的，有很多使用SVN或与之合作的各种工具。 一些例子包括：
- 与许多错误跟踪器或产品周期pipe理产品集成
- shell集成
- 融入各种产品
- 各种pipe理和分析工具
- 来源是可用的，你可以根据你的需要调整它，解决问题（或雇用人为你做），如果需要的话
成本
- 您不必支付任何许可证或维护费用
找一些借口开始在你的C＃代码中使用非ASCII字符 （中文和日文非常好）。
SourceSafe不喜欢Unicode（即使Visual Studio），所以如果你select正确的Unicode文本，并检查文件和退出，你的整个文件将显示为损坏的乱码。 这样做的好处在于，由于SS使用了“差异”版本控制系统，这实际上将文件损坏回原始的签入版本，并且不能自动修复。
当这只发生一次（正如我在处理一个必须支持日文的应用程序时所做的那样），您可能会发现它是支持删除SourceSafe的决定性论据。
我们用来销售pipe理的两个function和SVN上的VSS团队。
1）分支的能力。 当使用VSS时，当一个发布被安排出去，整个存储库被locking，直到发布实际上结束。 这包括testing和修复周期。 因此，开发人员无法提交除VSS存储库版本以外的任何其他内容。 这导致每次发布后立即进行长时间的集成会话。 通过在SVN中使用发布分支，不再需要locking整个存储库。
2）一次回滚整个更改的能力。 由于SVNlogging了在单个primefaces提交中更改的所有文件，因此恢复有问题的更改是微不足道的。 在VSS中，开发人员必须浏览整个存储库，并且几乎同时查找每个文件，然后逐个还原每个文件。 使用SVN，这与查找相关提交并触击TortoiseSVN中的“从此提交还原更改”button一样简单。
作为一个方面说明，我们使用TortoiseSVN，每个人都喜欢文件覆盖图标，以查看哪些内容没有改变。
无论你做什么，慢慢行动！ 在第一天不要开始和他们谈论分支 – 这会让他们失望。 我用这个评论对VSS用户进行了刻板印象，但这就是我所看到的。
对于开发人员：将其作为VSS的替代品出售，效果更好，速度更快。 在第一天使用VisualSVN，所以他们有一个超浅的学习曲线。 除了更快，更稳定的销售它们之外，两个人可以编辑同一个文件，并且不会因为一些文件上锁而导致某个人生病。
对于pipe理员来说：出售它们比VSS更稳定，更容易pipe理。 向他们展示VisualSVN服务器 。
祝你好运！
首先，logging您在源代码pipe理系统中遇到的所有问题，这些问题都可以追溯到根本原因。 跟踪他们一个月左右。 加上由于不使用而造成的错失机会。 （如果你说“不使用颠覆的机会成本”，你可能会打动一个MBAtypes的经理）。 这些数字实际上是机会成本的底线，因为如果你没有搞乱VSS的话，大概你可能一直在做的工作提供的不仅仅是你的小时费率。
例如，您是否遇到需要被多个人访问的文件被locking的问题？ 你有部分（非primefaces）签入问题吗？ 您是否遇到了难以跟踪软件发布并重新创build版本库的问题？ 获取代码副本到没有源安全客户端的服务器上有问题吗？ 自动构build和testingstream程是否存在问题？因为持续集成工具无法监视版本控制系统的更新吗？ 我相信你可以想到很多其他人。
如果你能够计算出由于资源安全和物品所带来的好处而产生的问题的大致时间/金钱成本（使用通用的数字，例如人工成本为100美元/小时或者仅仅是几小时）以及任何延迟交付成本的成本， 。 如果您已经收集了大约一个月左右的数据，则可以使用每月颠覆来显示收益。
然后呈现转向颠覆的大致时间/成本。 （设置和迁移代码大约需要8个小时，每个开发人员需要2个小时才能完成连接，签出和移动项目等等）风险很低，因为sourcesafe仍然在回滚。
如果成本高于每月的收益，则可以将成本除以收益计算出收回期。 你也应该累计3年左右，以显示长期利益。 再次强调，真正的机会成本不是直接可计算的，因为在试图pipe理sourcesafe中的非分支版本时，您可能已经增加了价值。
没有人推荐使用SourceSafe，甚至不是微软。 他们现在将为您提供一个（昂贵的）TFS许可证。 SourceSafe只是不可靠的。
我在这里写了： E2上的Visual SourceSafe 。 这有点咆哮，但那是因为我必须使用SourceSafe一段时间，而内存让我有点泡沫。
可靠性是会咬你的最大的一个。 但是在SVN或TFS中也可以使用这些特性：
TFS和SVN都有多个文件的primefaces提交，但是Sourcesafe不会 – 如果你一次签入两个文件，这不是一个操作，就像在一个文件中检查一样，然后在另一个文件中检查。 你可以在两者之间的状态，一个文件已经签入，但没有其他。
SourceSafe不保留已删除文件的历史logging，文件移动或重命名。
与初始印象相反，如果您设置了正确的选项，SourceSafe确实支持同时检出多个文件。 但是TFS，尤其是SVN更适合这种工作方式
与SourceSafe不同的是，TFS和SVN在互联网上的服务器上都能正常工作（TFS正好，SVN出色），而SVN可以很好地离线工作 – 例如，如果你在飞机上或火车上有一台笔记本电脑，并且没有networking，你仍然可以工作和比较到以前的修订甚至还原，因为要做的数据是在本地进行的。
正如其他人指出的，SourceSafe就像CVS一样是一个“死”的产品。 它没有被积极发展。 TFS和SVN将在未来一段时间有更新的版本。
VS的AnkhSVN插件相当不错。 它有一些古怪的，但总的来说很好。
令人信服的团队移动是艰苦的工作 – 我从来没有pipe理它:-(可能其中一个更实际的论点，虽然速度 – VSS是缓慢的，当你有一个1GB的源数据库和几个用户。
编辑自从我使用VSS以来，这已经很久了，我忘记了它被locking了！ 是的，正如这里所提到的，如果您拥有的开发人员不多，那么迁移到非排他性/合并更改模型的能力应该会有所帮助。 它节省了大喊大叫的“在办公室里可以常见的包含”！
你说：“为了说服你的团队转向像SVN这样的更好的解决scheme，你认为哪些论点最有用？”
如果你不知道这是一个更好的解决scheme，那么你为什么提出这个论点？ 如果你的思想已经足够争取一个解决scheme，你应该知道这些理由是什么。
你相信你应该转向更好的东西吗？ 那些是你的论点。 任何缺乏这些论点的声音听起来都只是个人喜好的问题。
TortoiseSvn （免费）非常适合浏览器集成，从上下文菜单中为您提供svn的所有function。
VisualSvn （商业版）使得将svn集成到Visual Studio中同样简单，在解决scheme浏览器中具有相同的状态指示以及使用所有Subversion特性的上下文菜单。
这两种工具都可以使版本控制无缝化。 自从我处理VSS以来，已经有两年多了，但是这些工具是使用源代码控制的更好的方法。
同样的， 每个人都说VSS是便便
Subversion对分支和合并有很好的支持……我不记得VSS在这个部门有什么function。 我记得当需要从VSS发布的时候，经历了一周的痛苦的团队合并，使用Subversion不再存在的痛苦。
首先search谷歌的绝对数量的网页描述VSS是多么糟糕，并与同事分享。
其次，跳过颠覆，直接转到合适的分布式SCM，比如git或mercurial 。 因为合并是分布式SCM的固有部分，所以它们必须比svn这样的集中式系统处理合并要好得多。 Subversion仍然试图改进自己，以便更好地处理分支，分布式系统的构build正确。
构build一些将VSS存储库镜像到SVN存储库的自动化
build立共识需要时间。 如果您的VSS存储库的SVN镜像始终可用，则转换将更容易。 镜子不一定是完美的 – 它只是可以使用。 现在有用于此目的的工具。
告诉他们把源代码当作金钱来对待，并将他们指向SourceSafe的大量例子。 像这样的事情不应该发生在一个适当的源代码pipe理系统。
反对SourceSafe的最佳理由是它不是 安全的 ，其他所有可能被称为“我们不需要的function”。
对我们来说，最重要的是VSS在VPN和低带宽酒店networking上的速度（即缺乏），以及试图穿越防火墙的问题，以便两个不同站点的两个团队能够快速，安全，可靠地从相同的代码库工作。 我们正在运行两个VSS存储库，并打包“交付”，这些“交付”必须合并到其他站点的存储库中，以保持同步。
团队抱怨了一会儿，但很快就把它解决了。 TortoiseSVN本身就非常出色，Visual Studio的AnkhSVN插件真正让每个人都转向了转换。
回想起来，我不能相信有多less“你能检查文件SoAndSo吗？” 我们发送的电子邮件，更不用说“SourceSafe已经closures，我们必须恢复存储库”电子邮件。
啧。 看完这个评论并写下这个回应后，我不敢相信我们只要我们这么做就忍受VSS了。
总结VSS问题的网页 – 只是将人员指向该URL
如果使用VisualSVN，团队不会错过VSS。 2人同时在一个文件上工作也是一个很大的卖点。
源安全性的不可靠性（“请修复存储库…”）对我们来说已经足够了。 讽刺的是（我从来没有测量过），SVN似乎总是比较快。 良好的并发检出/合并。
我总是认为这对于开发者来说几乎是太明显了。 SourceSafe似乎打破并经常死亡，不想取代它…
我build议你继续前进，并开始介绍最佳实践到你的资源安全使用，以期改变颠覆行为。 希望这将使你的实际颠覆迁移更容易，并给你时间sorting你的开发周期，分支策略等。 正常。
另一个要考虑的是你的发展过程。 源代码控制pipe理系统只是解决scheme的一部分，为了充分利用颠覆或其他任何产品，您可能会想要了解它的使用情况如何与您的代码审查，qa和构buildstream程进行交互。
我不记得任何喜欢该产品的SourceSafe用户。 你的同事真的喜欢吗？
我目前客户的使用情况与CVS有类似的问题。 既然“有用”，而且大多数人对此感到满意，我不能推动他们改变。 但每天我都希望他们会！
我们曾经使用SourceSafe。 然后，当我join这个团队的时候，我处于一个不同的位置，即使我们有一个相当不错的局域网，当我试图查看最新版本时，花了40分钟。 我说服他们转换到CVS（我们现在使用SVN），结账时间下降到几分钟。 SourceSafe太慢，无法在远程位置使用。
我们从SourceSafe移动到Source Gear Vault。 这个源代码控制引擎对于用于SourceSafe的某个源代码非常舒服。 我们最终决定在发生一些SourceSafe腐败事件之后做出改变，这些事件发生在关键时刻。 所以我的build议是把你的销售报告放在SourceSafes不可靠的地方。
当然，使用源码安全是否有足够的理由要迁移到其他源码控制系统？
我在以前的工作中使用了SVN和CVS，并转移到了使用Source Safe的公司（我们将迁移到SVN），只是使用VSS已经足够让我对此非常不喜欢了。 尽pipe我之前工作的许多同事都告诉我有关VSS的恐怖故事，但我认为自从使用VSS之后会变得更好。
不能编辑一个文件，因为别人正在编辑它是荒谬的。 我试图转移到更多的分布式版本控制系统，如Bazzar，它是由cannonical制作的，但是在可用的工具方面还不够成熟。
源代码安全解决scheme成为SVN帮助您几乎每一步的发展方向。
另外使用乌龟Svn使代码评论更容易。
只要你能够放牧一群猫。 我已经去过两次了，在这两种情况下，人们在看到灯光之前，在Source Safe中遇到了一些严重的问题。 另一方面，作为一名pipe理人员，我只是指导团队使用SVN，而且我们的生产力提高了300％（这是与印度和美国的一个团队合作的，我们之前的代码交换在svn之前需要很长时间）
Trac也安装在Subversion之上。 它是免费的，一个很好的方式来查看存储库（时间轴，维基等）
在您提出这些论点时，请考虑您是否需要解决贵公司可能使用开源工具的任何政策。 查看以前的问题的答案： 切换源控制
让他们使用它，他们将切换到其他东西:)
现在，认真地告诉他们使用它并不困难，许多我认识的开发者拒绝切换，因为他们把subversion翻译成unix和wierd命令，向他们展示像ToirtoiseSVN或VisualSVN这样的接口，告诉他们Subversion允许他们编辑相同的文件，而不像VSS那样强制locking。
最后但并非最不重要的是开源。 它比购买Team Foundation Server的成本更低，如果你环顾四周，你会发现小团队的开发人员在SVN上工作得很好。
我在一个小的开发团队中使用了SourceSafe，并负责保持它运行。
我发现数据库很容易被破坏，发生这种情况时没有太多的办法。 “修复”function（与大多数Microsoft修复function一样）只有98％的时间不工作。
当然，当我们的数据库变得腐败的时候，我们试图从我们的备份存档中恢复。 那是当我们发现SourceSafe的另一个坏消息：它的2GB档案限制。 几个月前，我们在我们的办公室做备份，直到我们意识到他们不能恢复和无用。
SourceSafe只是一个等待发生的灾难。
我计划在接下来的几个星期里放弃SourceSafe，经过十多年的发展。 大多数情况下，我一直在一个小型（<5人）团队的环境中使用它，而不必做很多分支，因为没有电话这样做。
然而，对于我来说，首要的问题是，这个该死的事情是很容易腐败 – 如果你有一个networking驱动器上的SS数据库（哈哈，数据库;随机命名文件的集合更准确地描述它） ，通过添加/签入操作，部分局域网连接出现问题 – 十次中有九次出现“无效句柄”，该死的东西以某种方式被破坏，然后你就可以使用分析工具玩俄罗斯轮盘赌了。
几个月前，我意识到，在过去的十年中，我一直在制作本地软件的源代码，因为我不信任源代码pipe理系统。 多浪费时间。
所以，这是。 我可能会使用Subversion和TortoiseSVN，因为我认为这个团队需要一个UI来缓解这个过渡。
在我之前的工作中，我们开始使用VSS，然后转移到SVN，从不回头。
刚开始一个新的工作，他们使用VSS，幸运的是上述问题正在使他们考虑使用SVN。
不能添加文件到项目，因为有人有项目文件签出真气！
– 李
