Yes*_*ke. 9 version-control visual-sourcesafe
本周我正在采访一家公司,我将成为唯一的初始开发者支持我正在接受工作的应用程序.因为这样的职位在细节上可能会有很大差异,所以我打算提倡一些能使这项工作可行的具体方法.
我正在考虑提出的一件事是倾向于将现有的源代码从SourceSafe(它当前驻留的地方)转移到更好的版本控制产品,如Perforce.
我在SourceSafe上遇到过许多糟糕的经历,导致永久文件锁定和代码损坏等大量问题.独自一人,我担心这些轶事听起来像"我想改变它,因为我不喜欢它." 如果我要提起这个话题,我想要一个扣篮案.
那么,SourceSafe被视为劣质产品的经验原因是什么？
Joh*_*ers 16
根据经验,将您宝贵的源代码信任到一个甚至达不到Microsoft Access可靠性水平的软件是没有意义的.该产品应该在几年前被倾销.这不符合现代标准.
我将它评为任何开源产品,如CVS或SVN,我不知道我在其下面评价的任何产品,除了可能是旧版本的VSS.
stu*_*rtd 12
有一个一长串的问题在这里(诚然,从2002年,但在产品还没有真正从那时起改变)
编辑:这是链接中的文本,以防它消失.Page根据CCA3获得许可.
作者:Alan De Smet
修订控制系统有许多优秀的解决方案. SourceSafe不是其中之一.
虽然2002年春天我使用了SourceSafe五年.它一直是一种不愉快的经历.新版本未能改进任何导入.我希望能阻止你使用SourceSafe,免除我的糟糕经历.
修订控制系统应提供强大的分支 支持.凭借强大的分支支持,开发人员可以轻松地对旧版本进行少量修订,同时继续为下一个主要版本工作.可以将高度实验性的代码检入分支,使其与主流开发分离,但将其备份并将其提供给其他开发人员.如果在构建里程碑或最终版本时项目被"冻结",则开发人员可以继续开发分支上的下一个版本.(或者更常见的是,可以为冻结创建新分支,同时在主分支上继续进行一般开发.当发布完成后,冻结分支上的更改可以合并回主分支.)SourceSafe的分支支持无法有效支持任何这一点.
通过强大的分支,修订控制系统还必须提供强大的合并支持,以协调不同的分支.至少,系统必须允许开发人员检查两个分支之间的差异,修改它们以创建合并版本,并在满意时检查它们.SourceSafe的合并支持与签入紧密集成,使得难以检查差异和在将其检入树之前测试建议的合并.由于支持水平较低,很容易将无效代码检入修订控制系统.
应该可以使用其他功能轻松扩展您的版本控制系统.发送总结签到的电子邮件的能力至关重要.与团队合作时,列出已签入文件的常规电子邮件以及与其关联的签入邮件确实有助于让每个人都了解最近的更改.您可能还需要添加过滤器以防止签入不符合特定要求的代码(标准版权声明或不编译).SourceSafe几乎不支持这一点.虽然有可能,但每个客户端都需要安装其他功能.如果单个客户端缺少扩展,它将悄然无法按预期运行.(有关详细信息,请参阅 Visual SourceSafe 6.0自动化.请查看"陷阱SourceSafe事件？概述"部分.)您可以 为第三方解决方案支付更多费用,但是在基础破坏的产品上投入更多资金是否有意义？
更新本地工作区以匹配服务器时,应提醒您注意在服务器上删除的文件.(或者删除,因为可以从修订控制系统中检索旧版本.)如果不这样做,可能会导致项目中使用过时的文件,这通常会导致问题.当我的项目中错误地包含过时的头文件时,我经常遇到这个问题.SourceSafe无法删除过期文件或提供任何警告.
SourceSafe无法通过慢速网络连接使用.它在公共互联网上实际上无法使用.此外,由于SourceSafe在网络共享上工作,如果将SourceSafe服务器放在Internet上,则会将服务器文件共享实现中的任何弱点暴露给整个世界.当然,如果您愿意在无效的修订控制系统上投入更多资金,您可以购买第三方产品来解决这个问题.
开发人员在项目中使用第三方模块快速添加所需功能的情况并不少见.例如,您可以使用Codejock Software的Xtreme Toolkit.将这些第三方模块检入您的修订控制系统是很自然的.这样,当您及时退步以检查先前的修订时,您可以获得相同版本的支持库和此时用于构建代码的第三方模块.
不幸的是,SourceSafe使跟踪第三方模块非常困难.最初检查第一个版本并不难.检查新版本需要良好的记忆力和对细节的关注.要添加新版本,首先递归检查保存模块的文件夹.现在删除磁盘上的目录并将其替换为新版本.检入新版本.您现在需要识别新版本中添加的任何文件或目录.右键单击SourceSafe中的模块文件夹,然后使用"显示差异"以递归方式生成已添加的文件列表.请注意哪些目录包含已添加的文件以及已添加的目录.现在关闭差异报告(报告是模态的,阻止您在可见时使用SourceSafe).像通常添加目录一样添加新目录.要添加新文件,请访问包含新文件的每个目录,然后使用"文件">"添加文件"添加它们.再次,使用"显示差异"命令以递归方式生成已删除的文件列表.请注意这些文件并再次关闭差异报告.现在删除SourceSafe中的每个文件.
如果您实际上已经调整了第三方模块,SourceSafe在追踪差异并将它们合并到新版本方面没有提供任何特别的帮助.
(为了比较,要使用CVS签入新版本的第三方模块,您只需运行命令"cvs -q import -m'导入Xtreme Toolkit 1.9'xtremetoolkit Codejock XT_1_9".就是这样.如果你已经对需要集成的模块进行了更改,您将使用"cvs checkout -j XT_1_8 -j XT_1_9 xtremetoolkit".这将为您提供合并更改的本地副本,如果满意,您可以立即签入.))
需要获取源代码的历史版本并不罕见.您可能需要较旧的版本来调查错误报告,或者当前代码出现故障,您需要获得正常运行的版本.SourceSafe支持这一点,但对于非平凡的项目来说它非常慢.要获得历史版本,首先需要为您感兴趣的整个项目生成历史记录.在包含数百个文件且历史超过一年的项目中,这可能需要五分钟以上(即使您限制实际搜索到最近48小时的变化).生成此历史记录后,您可以通过选择要接受的最后一个签入来指定要获取的版本.完成此过程的速度很慢,这阻碍了开发人员检查以前的版本,从而使修订控制系统失去了很多目的.
在对项目副本进行大量更改时,可能会要求您对项目进行少量更改.最有效和最安全的方法是获取项目的另一个副本以进行更改.SourceSafe提出了两个问题.首先,SourceSafe只识别系统上的项目的单个副本.您需要将项目目录移回SourceSafe期望规范副本的位置,或者您需要重置SourceSafe关于规范副本存在位置的概念.使用这两种技术,很容易意外地将SourceSafe指向错误的项目并检查错误的文件版本.其次,SourceSafe的弱合并功能意味着如果您需要在项目的两个副本中更改相同的文件,则需要要非常小心,对一个项目的更改不会破坏另一个项目的更改.
Microsoft建议您的数据库不超过5 GB.(来源:Microsoft Best Practices)虽然这是一个大型数据库,但对于大型项目来说并不合理,特别是如果您签入大型二进制文件(如Microsoft Word文档).
当您的系统失去与SourceSafe数据库的连接时,SourceSafe可能会挂起或崩溃.虽然这对Visual SourceSafe很恼火,但当Visual Studio使用SourceSafe集成时,这可能会导致您失去工作.简单地在Visual Studio中打开SourceSafe托管项目就足以让自己敞开心扉.为了最大限度地降低这种风险(并加速ClassView),我建议您 按照Microsoft关于禁用SourceSafe集成的说明进行操作.
SourceSafe并不真正作为服务器运行,而是作为一组通过SMB共享的文件运行.因此,您依靠每个客户都不会行为不端.单个行为不端的计算机可能会破坏数据库.操作系统上的文件共享实现中的问题可能会损坏数据库.只需要对修订控制系统进行只读访问的用户需要对服务器进行写访问,从而增加了风险(SourceSafe目录所需的网络权限).
当然,由于这种高风险的腐败,Microsoft建议您每周运行Analyze诊断程序.(来源:Microsoft最佳实践)当Analyze运行时,所有开发人员都 被锁定在系统之外(我希望每个人都记得先从SourceSafe退出!).我使用SourceSafe的经验表明,在Windows 2000下运行的2 GB系统需要几个小时来检查是否每周运行一次.
如果您的团队在不同的时区使用相同的SourceSafe存储库,则可能会遇到问题.(请参阅Microsoft有关时区错误的详细信息.)Microsoft提供的唯一解决方案是将计算机的时钟错误地设置为单个时区,或者购买第三方产品.
相关地,如果使用SourceSafe的任何客户端计算机无法同步时钟,则这是一个潜在的问题.计算机之间几分钟的差异可能会导致SourceSafe出现奇怪的行为,它会尝试协调看似来自未来的信息.
您的修订控制系统必须值得信赖.您将辛勤工作委托给您的修订控制系统.如果您的数据已损坏,则系统毫无价值.SourceSafe的基本设计假设客户端值得信赖,始终正常运行,并且没有任何因素干扰导致数据损坏的通信.因此,SourceSafe是脆弱和不值得信任的.我曾在三个不同的工作岗位上与SourceSafe合作过.在每种情况下,最终SourceSafe数据库都已损坏.数据已损坏,工作已丢失,时间浪费在问题上.在与其他开发人员交谈时,我了解到我的经历并不是独一无二的.
更改目录等次要操作会删除输出窗口的全部内容,从而难以检查过去的操作.
将本地版本与远程存储库进行比较是笨拙的.您选择您对SourceSafe感兴趣的目录,然后选择比较差异.生成的报告是模态的,阻止您在检查报告时使用SourceSafe.
从SourceSafe获取最新版本的文件时,每个本地更改的文件都会弹出一个对话框以确认更新.对话框等待您的响应时,更新操作完全停止.如果您获得最新版本,离开计算机一段时间,然后返回发现SourceSafe只完成了10%并等待您的响应,这尤其令人恼火.您可以通过多种方式阻止对话框返回,但这样做不会 表明遇到任何此类文件.因此,当您返回完成的更新时,您将不知道SourceSafe遇到了潜在的问题.SourceSafe在遇到时会在输出窗口中记下这些文件,这样可以轻松扫描输出窗口中的待调查文件.
如果您正在考虑使用SourceSafe,请考虑其他问题.如果您现在使用SourceSafe,请尽快迁移.这里仅仅是少数.
如果你只是必须使用的SourceSafe,肯定花时间去看看微软的错误清单中的Visual SourceSafe 6.0和修复的bug列表中的Visual SourceSafe 6.0,所以你知道会发生什么.(这些链接最初来自Microsoft的Bugs页面.如果您有不同版本的SourceSafe或上述链接失败,此页面可能会有用.)