锁定老帖子 主题:版本控制工具和重构的问题
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2004-01-07
1。可以支持并发开发 2。简单、不需要安装客户端,速度也还可以 3。有很多工具和cvs集成的挺好。 主要问题,因为可以并发开发,没有锁的机制,所以带来的问题是 如果程序员没有高度的责任心,又缺乏UT的习惯,每次合并更新的时侯 问题挺多的,而且容易互相扯皮,指责。另外如果项目开发中有大量公用的 xml等文本文件,将是一场灾难,cvs总是自以为是的加上一堆东西。 现在 我们用vss. vss主要的工作方式是用锁的机制,这带来新的问题。代码很难做重构。 总是有这个那个人check out出代码修改,而按照要求,在代码完成 测试之前是不应该check in的,所以很多的refactor只能不断的被推迟 最后迫于时间压力干脆放弃。 也因为这个锁的存在vss在用ant操作的时候,有些东西不够灵活。 很是有点烦。vss是公司级别用的,我们基本上是不可能修改的。 各位牛们给点意见呀。介绍一下你们的经验 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2004-01-07
为什么在代码完成测试之前不能够check in的呢?如果这样VSS Server上如何可以保证拥有代码的最新版本呢。其实我认为,最低限度,每天下班前必须要check in 自己的所有代码,而且需要没有编译错误,这是非常必要的.
关于用ant操作vss,我想询问一下,get by label的时候似乎有些source拿不下来,你是如何解决的呢? |
|
返回顶楼 | |
发表时间:2004-01-07
这本来就是个矛盾:要么大家同时改一个文件,然后Merge,要么你改完了我再改,这样最安全
虽然cvs允许你先改其它人改过的文件,可是你却冒了冲突的危险,所以我们在cvs下还是要等别人都commit以后再做重构,但这只能是纪律上的要求,就像你可以命令某个人不可以改某个目录下的文件,但是你还是无法保证这些文件100%的安全。团队越大,这方面管理起来就越困难,这时候就只有通过软件来帮助控制了。 |
|
返回顶楼 | |
发表时间:2004-01-07
yatwql 写道 为什么在代码完成测试之前不能够check in的呢?如果这样VSS Server上如何可以保证拥有代码的最新版本呢。其实我认为,最低限度,每天下班前必须要check in 自己的所有代码,而且需要没有编译错误,这是非常必要的.
关于用ant操作vss,我想询问一下,get by label的时候似乎有些source拿不下来,你是如何解决的呢? 这样就不可能作持续集成,而且矛盾挺多 |
|
返回顶楼 | |
发表时间:2004-01-07
首先你们要考虑集成的代价问题,有的集成一次需要太多的时间,这个时候对于checkin和checkout的要求要严格一些。但是如果我们采取普通增量集成,大版本彻底集成的方法,还是可以解决这些问题的。
而所谓的测试包括黑盒和白盒,集成测试之后是黑盒,这之前是白盒。当你的一个版本在没有经过充足的黑盒测试前肯定是即可以checkin也可以checkout的,因为这个时候通过checkin你已经得到了下一个版本。如果你发现问题可以采取分支合并的方法。如果你的SCM工具联这么简单的版本回溯功能都不能支持,那你还是换吧。不过至少CVS是支持版本回溯的,而不支持版本回溯的SCM工具我还真的没有见过(没有版本回溯能叫SCM工具吗?) checkin的关键是必须保证在checkin之前已经经过白盒测试了,保证程序是可以运行的了,并且保证单元测试和source已经同时checkin了。 现在我遇到的最主要的问题是,大家不喜欢经常的checkin和checkout。可以强制在checkin的同时checkout,同时规定每日必须checkin一次。 |
|
返回顶楼 | |
发表时间:2004-01-07
我觉得为了提高开发效率,其实可以对 Checkin 放松些要求。首先必须保证编译,另外尽量把对别人的影响降到最小。还有就是其实很多问题是开发过程中人的因素,不要指望采用工具后这些因素就会消失,这也是《人件》的观点。无论你采用 CVS 还是 VSS 都会有这些问题。
我觉得做测试驱动和持续集成要考虑成本。如果发现确实成本很高,不做测试驱动和持续集成又有何妨?是不是大师说必须要做测试驱动和持续集成我们就必须把这些做完做彻底?除了这些其实还有 Code Review 等提高代码质量的手段。大师总是假设我们有足够的时间完成项目,问题是我们常常没有足够的时间!XP 的目标可不是一般人想象的敏捷,XP 的假设是:如果你有足够的时间,你如何做软件开发?有些代码完全采用测试驱动的方式来开发确实很困难(举些例子,开发框架或者可重用的组件,还有那些复杂性非常高的代码),而且测试驱动在很多场合确实会带来成本的增加(例如测试代码与功能代码依赖关系的维护),这是我和 robbin 等一些朋友讨论后得到的共识。 为什么我要把测试驱动和持续集成放在一起说,就是因为没有自动测试的支持,持续集成得到的日创建是没有意义的。靠什么来证明这个创建是正确的?如果还是要靠人手工来测试,那样效率是非常低的。 说点实际的,我不认为 VSS 比 CVS 更好,比 CVS 更好的是 Subversion,而且 Subversion 可以自动将 CVS 的 Repository 转换为自己的格式。另外 VSS 好象也可以采用不加锁的方式。 |
|
返回顶楼 | |
发表时间:2004-01-07
cvs也具有你说的"锁"的功能,不过要用eclipse才行,绝对比vss好
|
|
返回顶楼 | |
发表时间:2004-01-08
不好意思,我只用过VSS.没用过CVS,所谓
可以采用不加锁的方式,在VSS中应该是指 get latest version吧,不过却没有修改的权限了 |
|
返回顶楼 | |
发表时间:2004-01-08
dlee 写道 我觉得为了提高开发效率,其实可以对 Checkin 放松些要求。首先必须保证编译,另外尽量把对别人的影响降到最小。还有就是其实很多问题是开发过程中人的因素,不要指望采用工具后这些因素就会消失,这也是《人件》的观点。无论你采用 CVS 还是 VSS 都会有这些问题。
我觉得做测试驱动和持续集成要考虑成本。如果发现确实成本很高,不做测试驱动和持续集成又有何妨?是不是大师说必须要做测试驱动和持续集成我们就必须把这些做完做彻底?除了这些其实还有 Code Review 等提高代码质量的手段。大师总是假设我们有足够的时间完成项目,问题是我们常常没有足够的时间!XP 的目标可不是一般人想象的敏捷,XP 的假设是:如果你有足够的时间,你如何做软件开发?有些代码完全采用测试驱动的方式来开发确实很困难(举些例子,开发框架或者可重用的组件,还有那些复杂性非常高的代码),而且测试驱动在很多场合确实会带来成本的增加(例如测试代码与功能代码依赖关系的维护),这是我和 robbin 等一些朋友讨论后得到的共识。 为什么我要把测试驱动和持续集成放在一起说,就是因为没有自动测试的支持,持续集成得到的日创建是没有意义的。靠什么来证明这个创建是正确的?如果还是要靠人手工来测试,那样效率是非常低的。 说点实际的,我不认为 VSS 比 CVS 更好,比 CVS 更好的是 Subversion,而且 Subversion 可以自动将 CVS 的 Repository 转换为自己的格式。另外 VSS 好象也可以采用不加锁的方式。 现在也是茅盾重重呀,以前考虑新手太多,就不严格要求了,结果几个星期一集成就一堆问题,不是少文件就是没更新。每次让他跑起来都要几个小时,还不要说测。前面看了potian的贴子,仔细想想还是做自动集成比较好。至少每天的夜集成可以让看看项目作成什么样了。其实我们现在提交到vss上的东西,现在个别连编译都不能通过,大家还是习惯bavss做备份工具,坏习惯害死人呀。 |
|
返回顶楼 | |
发表时间:2004-01-13
vss可以采用不加锁的机制,即设置选项允许multiple checkout,手头上没有VSS,所以不能详细说明,请自己查找一下
|
|
返回顶楼 | |