我的开发团队在非常基础的层面上使用源代码安全。我们正在进入一些更高级和扩展的开发周期，我不禁认为不使用分支和合并来管理更改很快就会对我们不利。
为了说服您的团队转向像 SVN 这样更好的解决方案，您认为哪些论点最有用？
您使用了哪些程序来弥补功能差距，以便团队不会错过 ide sourcesafe 集成？
还是我应该接受 sourcesafe 并尝试将更好的做法硬塞进去？
tom.dietrich
问问题
7039 次
34 回答
54
可靠性
- SVN 对于大型数据库更可靠
- SVN 仍然受到积极支持
- 原子提交 - 在 VSS 中，当您在另一个用户执行签入时获得最新版本时，您可能会获得不一致的状态，从而迫使您在更好的情况下重复“获取最新版本”，但有时如果不走运，您可能会留下一个代码库编译但不起作用。由于原子提交，这在 SVN 中不会发生。
特征
- SVN 分支/合并要好得多
- SVN 内置了对远程访问的支持
- SVN 更具可配置性（外部 Diff/Merge 工具的集成）
- SVN 更具扩展性（钩子）
更高的生产力
- SVN“更新”比SS “获取最新版本”快很多
- SVN 命令行更容易和更清洁 - 这对于自动构建或测试工具很有用
同级别的 IDE 集成
- 直到最近，VSS 的 VS 集成要好得多，但在AnkhSVN 2.0中，这不再适用。
打开
SVN是开放的，有很多使用SVN或与之合作的工具。一些例子包括：
- 与许多错误跟踪器或产品周期管理产品集成
- 外壳集成
- 集成到各种产品中
- 各种管理和分析工具
- 源可用，您可以根据需要对其进行调整，在需要时解决问题（或聘请某人为您做）
成本
- 您无需支付任何许可或维护费用
于 2008-09-22T15:40:09.467 回答
52
首先，教他们如何有效地使用 SourceSafe。
如果他们足够聪明，他们就会开始喜欢使用版本控制系统的好处，如果是这样，他们很快就会达到 SourceSafe 的极限。在那里，他们将更能倾听您关于切换到更好的 VCS 的论点，可以是 CVCS 还是 DVCS，具体取决于团队准备实现的目标。
如果你试图在他们以错误的方式使用 SourceSafe 时强迫他们使用另一个 VCS，比如保存源代码的 zip 文件（不要笑，他们两年前在我公司就是这样做的），他们将完全不情愿任何争论，尽可能好。
于 2008-09-22T15:31:43.450 回答
22
找一些借口开始在你的 C# 代码中使用非 ASCII 字符（中文和日文非常适合这一点）。
SourceSafe 不喜欢 Unicode（即使 Visual Studio 喜欢），因此如果您选择正确的 Unicode 文本并签入和签出文件，您的整个文件将显示为已损坏的乱码。这样做的美妙之处在于，因为 SS 使用“差异”版本控制系统，这实际上将文件一直损坏到原始签入版本，并且无法自动修复。
当这种情况只发生一次时（就像我在开发必须支持日语的应用程序时发生的那样），您可能会发现它是支持放弃 SourceSafe 的决定性论据。
于 2008-09-22T16:46:33.257 回答
16
我们曾经在 SVN over VSS 上销售管理和团队的两个功能。
1）分支能力。使用 VSS 时，当一个版本计划发布时，整个存储库都被锁定，直到该版本真正发布。这包括测试和修复周期。因此，开发人员除了对 VSS 存储库的版本进行修复之外，无法提交任何其他内容。这导致每次发布后立即进行长时间的集成会话。通过在 SVN 中使用发布分支，不再需要锁定整个存储库。
2) 一次回滚整个更改的能力。因为 SVN 在一个单一的原子提交中记录所有更改的文件，所以恢复有问题的更改是微不足道的。在 VSS 中，开发人员必须遍历整个存储库并找到几乎同时更改的每个文件，并将每个更改单独还原到每个文件。使用 SVN，这就像在 TortoiseSVN 中找到相关提交并点击“Revert Changes from this Commit”按钮一样简单。
附带说明一下，我们使用 TortoiseSVN，每个人都喜欢文件覆盖图标，因为它可以查看已更改和未更改的内容。
于 2008-09-22T15:40:20.247 回答
13
不管做什么，慢慢来！不要在第 1 天就开始与他们谈论分支——这只会让他们望而却步。我用该评论对 VSS 用户进行了刻板印象，但这就是我所看到的。
对于开发人员：将其作为 VSS 的替代品出售，效果更好更快。在第 1 天使用 VisualSVN，因此他们的学习曲线非常浅。以相同的方式出售它们，除了更快，更稳定，并且 2 个人可以编辑同一个文件，而且他们不会因为某些人因一堆文件而生病而生病。
对于管理员：以比 VSS 更稳定、更易于管理的方式出售它们。向他们展示VisualSVN 服务器。
祝你好运！
于 2008-09-22T15:35:17.123 回答
5
没有人推荐再使用 SourceSafe，甚至微软也不推荐。他们现在将为您提供（昂贵的）TFS 许可证。SourceSafe 只是不可靠。
我在这里写过：Visual SourceSafe on E2。这有点咆哮，但那是因为我不得不使用 SourceSafe 有一段时间了，而且记忆让我有点口吐白沫。
可靠性是会咬你的大问题。但也有一些您可能会喜欢 SVN 或 TFS 的功能：
TFS 和 SVN 都有多个文件的原子提交，但 Sourcesafe 没有 - 如果您“一次”签入两个文件，这不是一个操作，它与签入其中一个文件，然后签入另一个文件相同。您可以处于两者之间的状态，其中一个文件已签入，但另一个文件未签入。
SourceSafe 不保留已删除文件、文件移动或重命名的历史记录。
与最初的印象相反，如果您设置了正确的选项，SourceSafe 确实支持多个同时检出同一文件。但是 TFS 尤其是 SVN 更适合这种工作方式
与 SourceSafe 不同，TFS 和 SVN 都可以在 Internet 上的服务器上正常工作（TFS 还可以，SVN 非常好），而 SVN 在离线时也能很好地工作 - 例如，如果你在飞机或火车上有一台笔记本电脑，但没有网络，你仍然可以工作和比较到以前的修订版甚至恢复，因为这样做的数据是在本地保存的。
正如其他人所指出的，SourceSafe 与 CVS 一样，是一个“死”的产品。它没有被积极开发。TFS 和 SVN 将在未来某个时间推出下一个版本。
于 2008-09-22T15:42:55.077 回答
5
首先，记录您遇到的所有问题，这些问题可以追溯到源代码控制系统中的根本原因。跟踪他们一个月左右。再加上因不使用它而错过的机会。（如果你说“不使用颠覆的机会成本”，你可能会给 MBA 型经理留下深刻印象）。这些数字实际上是对机会成本的低估，因为如果您没有搞乱 VSS，大概您所做的工作可能会提供超过您的小时账单价值率。
例如，您是否遇到过需要多人访问的文件被锁定的问题？您是否遇到过部分（非原子）签入问题？您是否存在难以跟踪软件版本并像过去一样重新创建存储库的问题？在没有源安全客户端的服务器上获取代码副本时是否遇到问题？您是否因为持续集成工具无法监控您的版本控制系统的更新而在自动化构建和测试过程中遇到问题？我相信你能想到很多其他人。
如果你能计算出由 sourcesafe 引起的问题的大致时间/金钱成本以及 subversion 提供的东西的好处（使用一个通用数字，如人工成本 100 美元/小时或仅几个小时）以及延迟交付项目的任何成本，这样做. 如果您已经收集了一个月左右的数据，则可以使用 subversion per month 来显示收益。
然后介绍迁移到颠覆的大致时间/成本。（大约 8 小时来设置和迁移代码，每个开发人员需要 2 小时来连接、签出和移动项目，诸如此类）风险很低，因为 sourcesafe 仍然可以回滚。
如果成本超过每月收益，您可以将成本除以收益来计算恢复期。您还应该将其总计超过 3 年左右，以显示长期收益。再次强调，真正的机会成本不是直接可计算的，因为在您尝试在 sourcesafe 中管理非分支版本时，您可能一直在增加价值。
于 2008-09-22T17:02:40.440 回答
3
VS 的 AnkhSVN 插件非常好。它有一些奇怪的地方，但总的来说效果很好。
说服团队搬家是一项艰巨的工作——我从来没有做到过 :-( 可能更实际的论点之一是速度——当你有一个 1GB 的源数据库和几个用户时， VSS 很慢。
编辑我已经很久没有使用VSS了，我忘了它是锁定的！是的，正如这里提到的，如果您拥有多个开发人员，那么迁移到非独占/合并更改模型的能力应该会有所帮助。它省去了在办公室里大喊“有人可以检查公用包吗”！
于 2008-09-22T15:35:13.067 回答
3
你说“为了说服你的团队转向像 SVN 这样更好的解决方案，你认为哪些论点最有用？”
如果你不知道这是一个更好的解决方案，那你为什么要争论呢？如果你下定决心去争论解决方案，你应该知道这些原因是什么。
是什么让你相信你应该转向更好的东西？这些就是你的论点。任何缺少这些论点的东西听起来都只是个人喜好的问题。
于 2008-09-22T15:47:56.173 回答
3
TortoiseSvn（免费）非常适合浏览器集成，从上下文菜单中为您提供 svn 的所有功能。
VisualSvn（商业）使得将 svn 集成到 Visual Studio 中同样容易，在解决方案浏览器中具有相同的状态指示以及使用所有颠覆功能的上下文菜单。
这两种工具都有助于实现无缝的版本控制。自从我处理 VSS 以来已经有好几年了，但这些工具是使用源代码控制的更好方式。
Subversion 对分支和合并有很好的支持……我不记得 VSS 在这个部门有任何能力。我确实记得团队在需要从 VSS 发布时经历了长达一周的合并痛苦，而 Subversion 不再存在这种痛苦。
于 2008-09-22T16:42:06.713 回答
3
构建一些将 VSS 存储库镜像到 SVN 存储库的自动化
建立共识需要时间。如果您的 VSS 存储库的 SVN 镜像始终可用，那么累积转换将更容易。镜子不一定是完美的——它只需要可用。有用于此目的的现有工具。
于 2008-09-23T04:12:44.853 回答
2
对我们来说，关键是 VSS over VPN 的速度（即缺乏速度）和路上的低带宽酒店网络，以及试图通过防火墙的问题，以便两个不同站点的两个团队能够快速、安全和可靠地从同一个代码存储库工作。我们正在运行两个 VSS 存储库并打包必须合并到另一个站点的存储库以保持同步的“交付”。
队员们抱怨了一阵，但很快就克服了。TortoiseSVN 本身就很棒，Visual Studio 的 AnkhSVN 插件确实让每个人都轻松地进行了转换。
回想起来，我不敢相信有多少“你能签入 SoAndSo 文件吗？” 我们发送的电子邮件，更不用说“SourceSafe 已关闭。我们必须恢复存储库”电子邮件。
嘘。阅读此评论并撰写此回复后，我不敢相信我们能忍受 VSS 这么久。
于 2008-09-23T04:56:27.243 回答
2
总结 VSS 问题的网页- 只需将人们指向该 URL
于 2008-09-29T14:55:58.960 回答
1
如果您使用 VisualSVN，团队将不会错过 VSS。2 个人能够同时处理一个文件也是一大卖点。
于 2008-09-22T15:29:59.897 回答
1
源代码安全的不可靠性（“请修复存储库...”）对我们来说已经足够了。Andecdotally（我从未测量过）SVN 似乎也总是更快。良好的并发结帐/合并。
我一直认为这对开发人员来说太明显了。SourceSafe 似乎经常崩溃和死亡，不想更换它......
于 2008-09-22T15:32:08.333 回答
1
我不记得有任何 SourceSafe 用户喜欢该产品。你的同事真的喜欢它吗？
在我当前客户的使用中，我遇到了与 CVS 类似的问题。由于“它有效”并且他们大多对此感到满意，因此我无法推动他们改变。但我每天都希望他们会！
于 2008-09-22T15:33:42.103 回答
1
于 2008-09-22T16:08:53.580 回答
1
我建议您继续并开始在您的 sourcesafe 使用中引入最佳实践，以期进一步更改为 subversion。希望这将使您的实际颠覆迁移更容易，并让您有时间整理计划您的开发周期、分支策略等。适当地。
要考虑的另一件事是您的开发过程。源代码控制管理系统只是解决方案的一部分，为了充分利用 subversion 或任何其他产品，您可能想看看它的使用如何与您的代码审查、质量保证和构建过程交互。
于 2008-09-22T17:10:34.353 回答
1
当我参加 VS2005 的发布会时，我设法把一个微软人逼到了角落，问为什么 SourceSafe 用起来这么糟糕。我得到的答复相当令人震惊，不仅因为他说了什么，还因为他对自己所说的话如此坦率。
他告诉我，它真的只适合一个人使用，即使那样它也不是很擅长这样做。
我和我的同事有点震惊，除了大笑之外，我们想不出别的办法，Microsofty 也是如此！然后他告诉我们，它没有在内部使用。
所以，在那之后不久我们就切换到了颠覆。我们几乎决定在发布活动之前就这样做，但这只是证实了我们做出了正确的决定。
于 2010-02-19T21:29:58.550 回答
0
我们曾经使用 SourceSafe。然后，当我加入团队时，我在不同的位置，即使我们有一个相当不错的局域网，但当我尝试查看最新版本时却花了 40 分钟。我说服他们转换为 CVS（我们现在使用 SVN），结帐时间减少到几分钟。SourceSafe 太慢了，无法在远程位置使用。
于 2008-09-22T15:35:46.217 回答
0
我们从 SourceSafe 迁移到 Source Gear Vault。这个源代码控制引擎对于使用 SourceSafe 的人来说非常舒服。在发生了几起 SourceSafe 腐败事件后，我们最终决定做出改变，那是在关键时刻。因此，我的建议是将您的销售演示集中在 SourceSafes 的不可靠性上。
于 2008-09-22T15:40:49.513 回答
0
当然，使用源代码安全是要迁移到另一个源代码控制系统的充分理由吗？
我在以前的工作中使用了 SVN 和 CVS，并搬到了一家使用 Source safe 的公司（我们将迁移到 SVN），仅仅使用 VSS 就足以让我对它产生严重的反感。尽管我以前工作的许多同事告诉我有关 VSS 的恐怖故事，但我还是抱着开放的心态进入的，我认为自从他们使用它后它会变得更好。
无法编辑文件，因为其他人正在/正在编辑它是荒谬的。我试图转移到更分布式的版本控制系统，例如由 cannonical 制作的 Bazzar，但是就可用工具而言，它还不够成熟。
Source safe 阻碍了 SVN 几乎每一步都能帮助您的开发方式。
另外，使用 tortoise Svn 使代码审查变得更加容易。
于 2008-09-22T16:09:50.053 回答
0
仅在您能够放牧一群猫的范围内。我去过那里两次，在这两种情况下，在人们看到光明之前，Source Safe 都出现了一些严重的问题。另一方面，作为经理，我只是简单地指示团队使用 SVN，我们的生产力提高了 300%（这是与印度和美国的一个小组合作。在 svn 之前，我们进行了过去需要很长时间的代码交换）
于 2008-09-22T16:35:56.777 回答
0
Trac 也安装在 Subversion 之上。它是免费的，是查看存储库（时间线、wiki 等）的好方法
于 2008-09-22T18:21:48.423 回答
0
当您提出这些论点时，请考虑您是否需要解决您的公司可能制定的关于使用开源工具的任何政策。请参阅上一个问题的答案： 切换源代码控制
于 2008-09-22T18:28:58.970 回答
0
让他们使用它，他们将切换到其他东西:)
现在，说真的，告诉他们使用它并不难，我认识的许多开发人员拒绝切换，因为他们将颠覆与 unix 和奇怪的命令相关联，向他们展示像 ToirtoiseSVN 或 VisualSVN 这样的界面，告诉他们 Subversion 允许他们编辑同一个文件，无需像 VSS 那样强制锁定。
最后但同样重要的是，它是开源的。与购买 Team Foundation Server 相比，它的成本更低，并且如果您环顾四周，您会发现小型开发团队可以很好地使用 SVN。
于 2008-09-30T20:46:24.240 回答
0
我在一个小型开发团队中使用了 SourceSafe，并负责保持它的运行。
我发现数据库很容易被破坏，发生这种情况时没有太多的追索权。“修复”功能（与大多数 Microsoft 修复功能一样）在 98% 的情况下都无法正常工作。
自然，当我们的数据库损坏时，我们会尝试从备份存档中恢复。那时我们发现了 SourceSafe 的另一个坏处：它的 2GB 存档限制。在我们意识到它们无法恢复并且毫无用处之前，我们在办公室进行了几个月的备份。
SourceSafe 只是一场等待发生的灾难。
于 2008-10-23T13:24:20.180 回答
0
在忍受了十多年之后，我计划在接下来的几周内放弃 SourceSafe。大多数情况下，我一直在一个小型（< 5 人）团队的环境中使用它，并且不必做很多分支，因为没有人要求这样做。
然而，对我来说，第一大问题一直是，这该死的东西很容易损坏——如果你的 SS 数据库（哈哈，数据库；随机命名文件的集合更准确地描述它）在网络驱动器上，并且您的 LAN 连接在添加/签入操作的中途发生了一些事情 - 十分之九的时候您会收到“无效句柄”并且该死的东西以某种方式损坏，然后您可以使用分析器工具玩俄罗斯轮盘赌。
几个月前，我意识到，在过去的十年中，我一直在制作我正在开发的软件的每个版本的本地压缩副本，因为我不信任源代码控制系统。真是浪费时间。
所以，它正在发生。我可能会使用 Subversion 和 TortoiseSVN，因为我认为团队需要一个 UI 来简化过渡。
于 2008-10-23T13:36:18.813 回答
0
在我之前的工作中，我们从 VSS 开始，然后转到 SVN，并且从未回头。
刚开始新工作，他们使用VSS，幸运的是上述问题让他们考虑使用SVN。
因为有人签出项目文件而无法将文件添加到项目中，这真令人气愤！
——李
于 2009-08-23T17:19:04.090 回答
0
如果将 SourceSafe 用于另一个版本控制系统，我建议使用Mercurial而不是 SVN
Joel Spolsky 写了一篇非常好的Mercurial 介绍，您也可以使用Visual Studio 的插件。
于 2010-03-05T15:51:41.123 回答
0
每当我在一个 3 人的团队中工作时，他们开始增加人数，进一步远离 VSS 似乎是一个自然的步骤。
每当我向人们展示持续集成（特别是CruiseControl.NET）的好处时；这本身通常足以保证从 VSS 迁移到 SVN（我发现 SVN 在 CruiseControl.NET 上的效果比 VSS 好得多）。
我建议在 SVN 中启动任何新项目，并在必要时迁移旧项目，而不是一步完成从一个项目到另一个项目的完全迁移。
您会惊讶于 VSS 以这种方式消失的速度有多快。
于 2010-08-18T10:41:36.143 回答
0
一本关于这个主题的优秀书籍是“推动技术变革”。
于 2011-03-12T01:15:07.327 回答