我的开发团队在非常基础的层面上使用源安全。我们正在进入一些更高级和更长的开发周期，我不禁想到，为了管理变更而不使用分支和合并将很快咬住我们。
为了说服你的团队转向像SVN这样的更好的解决方案，你认为哪些论据最有用？
您使用哪些程序来弥合功能差距，以便团队不会错过ide sources的安全集成？
或者我应该接受sourcesafe并尝试将更好的做法塞进其中？
答案 0 :(得分：54)
SVN是开放的，有很多使用SVN或与之合作的各种工具。一些例子包括：
答案 1 :(得分：52)
首先，教他们如何以有效的方式使用SourceSafe。
如果他们足够聪明，他们将开始喜欢使用版本控制系统的优势，如果是这样，他们很快就会达到SourceSafe的极限。这就是他们能够更好地倾听你的论点以转换到更好的VCS，可能是CVCS还是DVCS，具体取决于团队准备实现的目标。
如果你试图以错误的方式使用SourceSafe时强迫他们使用另一个VCS，比如保存源代码的zip文件（不要笑，这就是两年前他们在我公司的行为），他们会完全不愿意任何论证，尽可能好。
答案 2 :(得分：22)
找一些借口在C＃代码中开始使用非ASCII字符（中文和日文非常适合这种情况）。
SourceSafe不喜欢Unicode（即使Visual Studio确实如此），因此如果您选择正确的Unicode文本并检查文件是否已退出，则整个文件将显示为损坏的乱码。这样做的好处在于，因为SS使用“diff”版本控制系统，这实际上会破坏文件一直回到原始签入版本，并且无法自动修复。
当这种情况发生一次时（正如我在处理必须支持日语的应用程序时所做的那样），你可能会发现它是支持放弃SourceSafe的决定性论据。
答案 3 :(得分：16)
我们曾经使用两个功能来销售管理层和SVN上的团队而不是VSS。
1）分支的能力。使用VSS时，如果计划发布一个版本，则整个存储库都会被锁定，直到该版本实际发布为止。这包括测试和修复周期。因此，开发人员无法提交除发布到VSS存储库的修复程序以外的任何。这导致每次发布后立即进行长时间的集成。通过在SVN中使用发布分支，不再需要锁定整个存储库。
2）能够立即回滚整个更改。因为SVN记录了在单个原子提交中更改的所有文件，所以恢复有问题的更改是微不足道的。在VSS中，开发人员必须遍历整个存储库并查找几乎同时更改的每个文件，并将每个更改单独还原到每个文件。使用SVN，这与查找相关提交并点击TortoiseSVN中的“从此提交中恢复更改”按钮一样简单。
作为旁注，我们使用TortoiseSVN，每个人喜欢文件覆盖图标，以查看已经发生的变化。
答案 4 :(得分：13)
无论你做什么，都要慢慢行动！不要在第1天开始和他们谈论关于分支的问题 - 它会把它们关掉。我用那个评论对VSS用户刻板印象，但这就是我在那里看到的。
对于开发人员：将其作为VSS的替代品销售，以更好，更快地运行。在第1天使用VisualSVN，因此它们具有超浅的学习曲线。除了更快，更稳定之外，卖掉它们是相同的，并且2个人可以编辑同一个文件，并且他们不会遇到一些人因为一堆文件上的锁而生病的问题。
对于管理员：销售它们比VSS更稳定，更易于管理。向他们展示VisualSVN server。
祝你好运！答案 5 :(得分：5)
首先，记录您在源控制系统中可以追溯到根本原因的所有问题。跟踪它们一个月左右。添加由于不使用它而导致错失的机会。 （如果你说“不使用颠覆的机会成本”你可能会给MBA类型的经理留下深刻的印象）。这些数字实际上是对机会成本的低估，因为如果你没有搞乱VSS，你可能一直在做的工作提供超过你的每小时票据费率。
例如，您是否遇到需要多个人访问的文件被锁定的问题？ 部分（非原子）签到有问题吗？ 您是否遇到过难以跟踪软件版本并重新创建存储库的问题？ 在将代码副本复制到没有sourcesafe客户端的服务器上时是否有问题？ 您是否在构建和测试过程自动化方面遇到问题，因为持续集成工具无法监控版本控制系统的更新？ 我相信你能想到很多其他人。
如果你能算出因源安全引起的问题的大致时间/金钱成本以及颠覆所提供的东西的好处（使用通用数字，例如100美元/小时的劳动力成本或仅数小时）以及延迟交付项目的任何成本， 这样做。如果您已经收集了一个月左右的数据，则可以使用每月的subversion显示收益。
然后呈现移动到颠覆的大致时间/成本。 （大约需要8个小时来设置和迁移代码，每个开发人员需要2个小时来连接，签出和移动项目，类似的东西）风险很低，因为sourcesafe仍然可以回滚到。
如果成本超过每月福利，您可以将成本除以福利以计算恢复期。您还应该将其总计超过3年左右，以显示长期效益。再次强调，真正的机会成本不能直接计算，因为在尝试管理sourcesafe中的非分支版本时，您可能一直在增加价值。
答案 6 :(得分：5)
没有人建议再使用SourceSafe，甚至不推荐使用Microsoft。他们现在将为您提供（昂贵的）TFS许可证。 SourceSafe不可靠。
我在这里写到：Visual SourceSafe on E2。这有点像咆哮，但那是因为我不得不使用SourceSafe很长一段时间，记忆让我有点泡沫。
可靠性是咬你的最重要的因素。但是你也可以在SVN或TFS中欣赏这些功能：
TFS和SVN都有多个文件的原子提交，但Sourcesafe没有 - 如果你“同时”签入两个文件，那么它不是一个操作，它与检入其中一个文件相同，然后检入其他。您可以进入两个状态，其中一个文件已经签入，而另一个文件没有。
SourceSafe不会保留已删除文件，文件移动或重命名的历史记录。
与初始展示相反，如果您设置了正确的选项，SourceSafe确实支持同一个文件的多个同时签出。但是TFS，特别是SVN更适合这种工作方式
与SourceSafe不同，TFS和SVN都能很好地对抗互联网上的服务器（TFS只是OK，SVN非常出色），SVN可以很好地离线工作 - 例如如果你在飞机或火车上有一台笔记本电脑并且没有'网络，你仍然可以工作并与以前的修订进行比较甚至还原，因为这样做的数据是在本地保存的。
正如其他人所指出的，SourceSafe与CVS一样，是一种“死”的产品。它没有得到积极发展。 TFS和SVN将在未来的某个时间推出下一版本。
答案 7 :(得分：3)
VS的AnkhSVN插件非常好。它有一些奇怪的东西，但整体上运作良好。
说服团队努力工作是一项艰苦的工作 - 我从来没有做过这样的事情:-(当你拥有1GB的源数据库时，可能其中一个更实际的论点就是速度 - VSS 慢几个用户。编辑自从我使用VSS以来已经很久了，我忘了锁定了！是的，正如这里提到的，如果你有超过少数开发人员，那么迁移到非独占/合并更改模型的能力应该会有所帮助。它可以在整个办公室中大肆宣传“有人可以检查共同的内容”！
答案 8 :(得分：3)
构建一些将VSS存储库镜像到SVN存储库的自动化
建立共识需要时间。如果VSS存储库的SVN镜像始终可用，则更容易累积转换。镜子不一定非常完美 - 它必须是可用的。现有工具用于此目的。
答案 9 :(得分：3)
首先搜索google，了解描述VSS有多糟糕的大量网页，并与同事分享。
其次，跳过subversion并直接转到适当的分布式SCM，如git或mercurial。由于合并是分布式SCM的固有部分，因此它们必须比svn等集中式系统更好地处理合并。 Subversion仍在尝试改进自身以更好地处理分支，其中分布式系统是在开始时正确构建的。
答案 10 :(得分：3)
TortoiseSvn（免费）非常适合资源管理器集成，从上下文菜单中为您提供svn的所有功能。
VisualSvn（商业）使得将svn集成到Visual Studio中同样容易，在解决方案浏览器中使用相同的状态指示以及使用所有subversion功能的上下文菜单。
这两种工具都可以很好地实现版本控制。自从我处理VSS以来，这是一个多年的轿跑车，但这些工具是使用源代码控制的一种更好的方式。
同样为every one has said about VSS being poop
Subversion对分支和合并有很好的支持......我不记得VSS在这个部门有任何能力。我确实记得当需要从VSS中释放时，团队经历了为期一周的合并的痛苦，这种痛苦在Subversion中不再存在。
答案 11 :(得分：3)
你说“为了说服你的团队转向像SVN这样的更好的解决方案，你认为哪些论据最有用？”
如果您不知道这是一个更好的解决方案，那么您为什么要提出这些论点？如果你的思想足以支持解决方案，你应该知道这些原因已经存在。
是什么让你相信你你应该转向更好的事情？那些是你的论点。任何缺乏这些论点的人都会觉得这只是个人偏好的问题。
答案 12 :(得分：2)
告诉他们将源代码看作是金钱，然后将它们指向SourceSafe的众多例子，这些例子都是火上浇油的源头。这样的事情不应该发生在适当的源控制系统中。
答案 13 :(得分：2)
我们的关键是VSS在VPN和路上的低带宽酒店网络上的速度（即缺乏）以及试图穿过防火墙的问题，以便两个不同站点的两个团队可以快速，安全地，并可靠地使用相同的代码存储库。我们运行了两个VSS存储库并打包了“交付”，必须将它们合并到另一个站点的存储库中以保持同步。
团队抱怨了一会儿，但很快就克服了它。 TortoiseSVN本身就很棒，Visual Studio的AnkhSVN插件真的让所有人都能顺利完成转换。
回想起来，我简直不敢相信“你能查到档案SoAndSo吗？”我们发送的电子邮件，更不用说“SourceSafe已关闭。我们必须恢复存储库”电子邮件。
啧。在阅读了这些评论并撰写此回复之后，我无法相信我们会像我们一样忍受VSS。
答案 14 :(得分：2)
Web page summarising problems with VSS - 只需将人们指向该网址
即可答案 15 :(得分：1)
答案 16 :(得分：1)
如果您使用VisualSVN，团队将不会错过VSS。能够同时处理一个文件的2个人也是一个很大的卖点。
答案 17 :(得分：1)
源安全的不可靠性（“请修复存储库......”）对我们来说已经足够了。 Andecdcdally（我从未测量过）SVN也似乎总是更快。良好的并发结账/合并。
我总是认为对开发者来说这几乎是显而易见的。 SourceSafe似乎经常破裂而死，不想替换它......
答案 18 :(得分：1)
当我在VS2005的发布时，我设法转向一个Microsofty，并问为什么SourceSafe使用起来非常糟糕。我得到的答复相当令人震惊，不仅仅是因为他说了什么，而是因为他对他所说的内容非常关注。
他告诉我，这只是一个人真正意义上的使用，即便如此，也不是很擅长这样做。
我的同事和我有点震惊，除了笑声之外我们想不出别的事情，就像微笑一样！然后他告诉我们它没有在内部使用。
因此，我们在此之后不久就转向颠覆。我们几乎决定在发布会之前去做，但这刚刚确认我们做出了正确的决定。
答案 19 :(得分：1)
我建议你继续开始为源安全使用引入最佳实践，以便进一步改进subversion。希望这将使您的实际颠覆迁移更容易，并给您时间来计划您的开发周期，分支策略等。正常。
另一件需要考虑的事情是您的开发过程。源控制管理系统只是解决方案的一部分，为了充分利用颠覆或任何其他产品，您可能希望了解它的用法如何与您的代码审查，qa和构建过程进行交互。
答案 20 :(得分：1)
我不记得任何有兴趣使用该产品的SourceSafe用户。你的同事真的喜欢吗？
我在当前客户的使用情况下遇到了与CVS类似的问题。既然“它有效”并且他们对它很满意，我无法推动它们改变。但我每天都希望他们愿意！
答案 21 :(得分：0)
关于这一主题的优秀书籍是“推动技术变革。”
答案 22 :(得分：0)
每当我在3人团队中工作并且他们开始增加数量时，进一步远离VSS似乎是一个自然的步骤。
每当我向人们展示Continuous Integration（特别是CruiseControl.NET）的好处时;这本身就足以保证从VSS转移到SVN（我发现SVN在使用CruiseControl.NET时比VSS更好）。
我建议在SVN中启动任何新项目，并在必要时迁移旧项目，而不是一步完成从一个项目到另一个项目。
你会惊讶于VSS以这种方式消失的速度。
答案 23 :(得分：0)
如果将SourceSafe放到另一个版本控制系统上，我建议使用Mercurial而不是SVN
Joel Spolsky写了一篇非常好的introduction to Mercurial，你也可以使用plug-in for Visual Studio。
答案 24 :(得分：0)
在我之前的工作中，我们开始使用VSS然后转移到SVN并且从未回头。
刚刚开始新工作，他们使用VSS，幸运的是上述问题让他们考虑使用SVN。
无法将文件添加到项目中，因为有人检查了项目文件是令人愤怒的！
- 李
答案 25 :(得分：0)
我计划在接下来的几周内放弃SourceSafe，经过十多年的努力。大多数情况下，我一直在小型（<5人）团队的背景下使用它，而不必进行大量分支，因为没有要求这样做。
然而，对我来说，＃1问题一直是，该死的东西很容易腐败 - 如果你有你的SS数据库（lol，数据库;随机命名文件的集合更准确地描述它）一个网络驱动器，你的局域网连接通过添加/签入操作中途发生了一些事情 - 十分之九你得到“无效句柄”，该死的东西在某种程度上被破坏了，然后你可以玩俄罗斯轮盘赌分析工具。
几个月前我意识到，在过去的十年里，我一直在为我正在开发的软件的每个版本制作本地压缩源副本，因为我不相信源代码控制系统。真是浪费时间。所以，它会发生。我可能会使用Subversion和TortoiseSVN，因为我认为团队需要一个UI来简化过渡。
答案 26 :(得分：0)
我在一个小型开发团队中使用了SourceSafe，并负责让它继续运行。
我发现数据库很容易被破坏，并且在发生这种情况时没有太多的追索权。 “修复”功能（与大多数Microsoft修复功能一样）在98％的时间内都不起作用。
当然，当我们的数据库损坏时，我们尝试从备份存档中恢复。那是我们发现SourceSafe的另一个坏处：它的2GB存档限制。在我们意识到它们无法恢复并且无用之前，我们在我们的办公室进行了几个月的备份。
SourceSafe只是一场等待发生的灾难。
答案 27 :(得分：0)
让他们使用它，他们会切换到别的东西：）
现在，说实话，告诉他们不是很难用它，我所知道的许多开发人员拒绝切换，因为他们将subversion与unix和wierd命令相关联，向他们展示像ToirtoiseSVN或VisualSVN这样的接口，告诉他们Subversion允许他们编辑同一个文件，而不像VSS那样强制锁定。
最后但并非最不重要的是，它是开源的。它比购买Team Foundation Server的成本更低，如果你环顾四周，你会发现小型开发团队与SVN的合作非常好。
答案 28 :(得分：0)
当您提出这些论点时，请考虑您是否需要解决贵公司可能使用开源工具的任何政策。请参阅先前问题的此答案：Switching source control
答案 29 :(得分：0)
Trac也安装在Subversion之上。它是免费的，是查看存储库（时间轴，维基等）的好方法
答案 30 :(得分：0)
我们曾经使用过SourceSafe。然后，当我加入团队时，我在不同的位置，即使我们有一个相当不错的局域网，当我试图查看最新版本时花了40分钟。我说服他们转换为CVS（我们现在使用SVN），结账时间下降到几分钟。 SourceSafe太慢，无法在远程位置使用。
答案 31 :(得分：0)
我们从SourceSafe迁移到Source Gear Vault。这个源代码控制引擎非常适合用于SourceSafe的人。我们最终决定在关键时刻发生几起SourceSafe腐败事件后进行更改。因此，我的建议是将您的销售演示重点放在SourceSafes的不可靠性上。
答案 32 :(得分：0)
只有你可以放牧一堆猫。我去过那里两次，在两种情况下，在人们看到光之前，它在Source Safe中遇到了一些严重的问题。另一方面，作为经理，我只是指导团队使用SVN，我们的工作效率提高了300％（这与印度和美国的一个团队合作。我们的代码交换过去需要很长时间才能在svn之前）
答案 33 :(得分：0)
当然，使用源安全是否足以让他们想要迁移到另一个源控制系统？
我在我以前的工作中使用了SVN和CVS并且已经转移到使用Source safe的公司（我们将迁移到SVN）并且仅仅使用VSS已足以让我严重不喜欢它。尽管我以前的工作中有很多同事告诉我关于VSS的恐怖故事，但我认为自从他们使用它之后它会变得更好。我带着开放的心态进去了。
无法编辑文件，因为其他人正在/正在编辑它是荒谬的。我试图转向更多的分布式版本系统，如Bazzar，这是由cannonical制作的，但就可用工具而言还不够成熟。
源安全阻碍了开发，SVN几乎可以帮助您完成每一步。
另外使用tortoise Svn使代码审查变得更加容易。