我如何说服我的团队放弃sourceafe并转移到SVN？

Question

我的开发团队在非常基础的层面上使用源安全.我们正在进入一些更高级和更长的开发周期,我不禁想到,为了管理变更而不使用分支和合并将很快咬住我们.

为了说服你的团队转向像SVN这样的更好的解决方案,你认为哪些论据最有用？

您使用了哪些程序来弥合功能差距,以便团队不会错过ide sources的安全集成？

或者我应该接受sourceafe并尝试将更好的做法纳入其中？

Answer 1

可靠性

• 对于大型数据库,SVN更可靠
• SVN仍然得到积极支持
• 原子提交 - 在VSS中,当你获得最新版本而另一个用户正在执行checkin时,你可能会得到一个不一致的状态,强迫你重复"获取最新版本"更好的情况,但有时不幸的是你可能会留下一个代码库编译但不起作用.由于原子提交,这在SVN中不会发生.

特征

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

提高生产力

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

相同级别的IDE集成

• VSS直到最近才有更好的VS集成,但是对于AnkhSVN 2.0,这已不再适用.

打开

SVN是开放的,有很多使用SVN或与之合作的各种工具.一些例子包括:

• 与许多bug跟踪器或产品周期管理产品集成
• shell集成
• 融入各种产品
• 各种管理和分析工具
• 来源可用,您可以根据需要进行调整,在需要时解决问题(或聘请某人为您服务)

成本

• 您无需支付任何许可证或维护费用

Answer 2

首先,教他们如何以有效的方式使用SourceSafe.

如果他们足够聪明,他们将开始喜欢使用版本控制系统的优势,如果是这样,他们很快就会达到SourceSafe的极限.这就是他们能够更好地倾听你的论点以转换到更好的VCS,可能是CVCS还是DVCS,这取决于团队准备实现的目标.

如果你试图强迫他们使用另一个VCS,当他们以错误的方式使用SourceSafe时,比如保存源代码的zip文件(不要笑,这就是两年前他们在我公司的行为),他们将完全不情愿任何论证,尽可能好.

Answer 3

找一些借口在C#代码中开始使用非ASCII字符(中文和日文都很适合).

SourceSafe不喜欢Unicode(即使Visual Studio确实如此),因此如果您选择正确的Unicode文本并检查文件是否已退出,则整个文件将显示为损坏的乱码.这样做的好处是,因为SS使用"diff"版本控制系统,这实际上会破坏文件一直回到原始签入版本,并且无法自动修复.

当这种情况发生一次时(正如我在处理一个必须支持日语的应用程序时所做的那样),你可能会发现它是支持放弃SourceSafe的决定性论据.

Answer 4

我们曾经通过VSS销售管理层和SVN团队的两个功能.

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

2)能够立即回滚整个更改.因为SVN记录了在单个原子提交中更改的所有文件,所以恢复有问题的更改是微不足道的.在VSS中,开发人员必须遍历整个存储库并查找几乎同时更改的每个文件,并将每个更改单独还原到每个文件.使用SVN,这与查找相关提交并点击TortoiseSVN中的"从此提交还原更改"按钮一样简单.

作为旁注,我们使用TortoiseSVN,每个人都喜欢文件覆盖图标,以查看已经发生的变化.

Answer 5

无论你做什么,慢慢移动!不要在第1天开始和他们谈论关于分支的问题 - 它会把它们关掉.我用那个评论对VSS用户刻板印象,但这就是我在那里看到的.

对于开发人员:将其作为VSS的替代品销售,以更好,更快地运行.在第1天使用VisualSVN,因此它们具有超浅的学习曲线.除了更快,更稳定之外,卖它们是相同的,2个人可以编辑同一个文件,并且他们不会遇到一些人因为一堆文件上的锁而生病的问题.

对于管理员:销售它们比VSS更稳定,更容易管理.向他们展示VisualSVN服务器.

祝好运!

Answer 6

没有人建议再使用SourceSafe,甚至不推荐使用Microsoft.他们现在将为您提供(昂贵的)TFS许可证.SourceSafe不可靠.

我在这里写到:E2上的Visual SourceSafe.这有点咆哮,但那是因为我不得不使用SourceSafe很长一段时间,记忆让我有点泡沫.

可靠性是咬你的大事.但是您也可以在SVN或TFS中欣赏以下功能:

TFS和SVN都有多个文件的原子提交,但Sourcesafe没有 - 如果你"同时"检入两个文件,它不是一个操作,它与检入其中一个文件相同,然后检入另一个.你可以进入两个状态,其中一个文件已经签入,而另一个文件没有.

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

与初始印象相反,如果您设置了正确的选项,SourceSafe确实支持同一个文件的多个同时签出.但是TFS尤其是SVN更适合这种工作方式

与SourceSafe不同,TFS和SVN都可以很好地对抗互联网上的服务器(TFS只是OK,SVN非常出色),SVN可以脱机工作 - 例如,如果您在飞机或火车上有笔记本电脑而没有网络,您仍然可以工作和比较以前的修订甚至还原,因为这样做的数据是在本地保存的.

正如其他人所指出的那样,SourceSafe与CVS一样,是一种"死"的产品.它没有得到积极发展.TFS和SVN将在未来的某个时间推出下一版本.

Answer 7

首先,记录您在源控制系统中可以追溯到根本原因的所有问题.跟踪它们一个月左右.添加由于不使用它而导致错失的机会.(如果你说"不使用颠覆的机会成本"你可能会给MBA类型的经理留下深刻的印象).这些数字实际上是机会成本的低估,因为如果你没有搞乱VSS,大概你可能一直在做的工作提供超过你的每小时的账单价值.

例如,您是否遇到需要由多个人访问的文件被锁定的问题？部分(非原子)签到有问题吗？您是否遇到过难以跟踪软件版本并重新创建存储库的问题？在将代码副本复制到没有sourcesafe客户端的服务器上时是否有问题？您是否在构建和测试过程自动化方面遇到问题,因为持续集成工具无法监控版本控制系统的更新？我相信你可以想到很多其他人.

如果你能算出由源安全引起的问题的大致时间/金钱成本和颠覆提供的东西的好处(使用通用数字,如人工成本或仅几小时100美元/小时)和延迟交付项目的任何成本,那么这样做.如果您已收集一个月左右的数据,则可以使用每月的subversion显示收益.

然后介绍移动到颠覆的大致时间/成本.(大约8个小时来设置和迁移代码,每个开发人员需要2个小时才能连接,签出和移动项目,类似的东西)风险很低,因为sourcesafe仍然可以回滚到.

如果成本高于每月福利,您可以将成本除以福利以计算恢复期.您还应该将其总计超过3年左右,以显示长期效益.再次强调,真正的机会成本不能直接计算,因为在尝试管理sourcesafe中的非分支版本时,您可能一直在增加价值.