版本控制工具和重构的问题

借贴请教:

我现在头痛的问题是,每天提供或经常提交,导致文件的版本太多,都不知哪些版本是有用的,哪些是过渡的了.

写注释? 做tag? or...?

另一个问题是,哪一个软件可以帮助CVS回滚最近一次,甚至是最近几次的提交? 我看potain的文章有提及,但在这里想听听大家的推荐.

头痛！ 经常提交。。 也不是什么坏习惯吧。：）
用tag来标示重要的历程碑。 至于反复提交，如果是版本 之间的修正，可以使用分差（？），其实我也是从eclipse的帮助看到的。
感觉用法很多。

这个我知道，不过还是没有解决一些问题

大家如果有兴趣的话，可以看一看
http://douleimi.vicp.net/space/Eclipse%20Team 下面的内容，希望提出宝贵意见
有两点说明一下：
1.这是一个很不完整和临时的log，所以不免出现很多偏差
2。这些模式适合Agile方式的开发，可能不适合很多其他的公司和团队场合

上面大家谈到的主要是2个问题
1。稳定性和并发程度的问题
锁定则并发行低，但你可以保证每次Update下来的代码是正确的，不会被相互覆盖，不锁定则并发性高，但可能产生冲突，需要排除的时间和精力
2。集成的频率和预检查的程度
集成频率高则每次集成的难度小，但是你的独立工作很容易受到其他程序员的影响，预检查越细致则出现集成构造步成功的可能性就越小，但每次需要预检查很长时间，会打击Commit的积极性，集成频率下降。

在团队协作开发的过程中，还有很多这样类似的问题，由于这些都属于权衡(force)的问题，所以我觉得用模式解释比较恰当。我主要采用了亚力山大的风格，所以不熟悉的人可能会觉得比较别扭。模式的最大好处试可以讨论各种权衡的优缺点，可以知道为什么这样做，这样做的后果，以及选择其他方式可能产生的问题。

团队开发的主题是保持独立性、可控性和支持快速变化、快速交流反馈之间的权衡（不管是代码、设计、版本等等）。相对于传统的方式，Agile团队比较偏向于后者，而Agile依靠一定的纪律对这种快速反馈可能产生的混乱进行控制，按照ASD的说法是“保持在混沌的边缘“
------------------------------------------------------------------------------------

我也没有加入Eclipse里面的具体操作方式，主要原因是我还没有把模式写完。但所有这些模式基本上是我实际项目中对项目管理员和程序员的要求，至少在Eclipse开发Java程序的过程中，这些模式的要求基本上可以不折不扣地执行下去。辅助工具主要包括JUNit,Ant ,CC(AntHill),javancss,CVS(TeamStar,Subversion),cactus和Grinder。

前期可以对类似的版本控制软件进行培训，再有就是重复那样的话，“责任心，协作性”，没有这些，再好的版本控制，也是会有纰漏的，关键还是人，有时强制是必须的

对于一个文件多人修改的问题,要看情况.
1.如果文件可以按人员划分区间,则可以在文件内部,分成若干段,每隔段之前有负责人的名字.这样,冲突的文件很容易合并.
2.如果文件不可以换分段,则最好由1个人进行维护.有问题,统一通过这个人修改.

对于重构代码是的问题
1.如果仅仅是影响自己的代码,则可以进行重构.
2.如果影响到个别人的代码,则需要提前通知他,然后进行重构,当然,被影响的人可以不提前提交代码,只要在重构之后的代码上继续开发就行.其间,使用Eclipse的合并功能,很容易合并差异代码.
3.如果影响范围很广,则通知全体,在下班之前提交代码,然后由专人进行重构,争取在上班之前做完.然后各个人员下载并合并代码.如果重构时间较长,则比较麻烦.各个人员也可以进行各自的开发,不过等到系统重构之后,需要合并也有的代码和自己的进度.这个时候Eclipse的超强功能就能体现出来了。