从TeamSource到WinCVS

 

技术文章

:: 从TeamSource到WinCVS

 

 

作    者:       Musicwind

版    本:       1.0

日    期:      2004-7-2

 

■ 修订人	修订描述	修订日期	审核人
Musicwind	o 创建此文档； o Musicwind保留修改、出版的权利。	2004-7-2

 

 

1       遥想TeamSource当年

工作之后使用的第一个版本管理工具便是TeamSource。因为它是Delphi安装包自带的，因此顺手就拿来用了。先是使用delphi 5.0下的那个版本，后来从delphi 6.0的安装包发现了更新的版本，即build 6.0.0.0，于是就一直用它，用了快3年。

那时候用TeamSource，不管文档、代码、程序、rar，只要是文件，就一股脑儿往TeamSource里面扔。搞得存放teamsource的硬盘都快吃不消了。

用teamsource最不方便的就是不稳定——不是出现异常要退出，就是让我无缘无故地丢数据，或者是因为几个客户端、服务端时间不同步导致版本错乱。唉！

就在数月以前，迫于种种情势，我们终于放弃了teamsource的使用，代之以cvs——我们在一台win2000 server上安装了cvsNt，然后在客户端使用wincvs。

有句话说，没有功劳也有苦劳。我们对Teamsource的功能作用以及存在的问题作个小小的总结，也算是对它的一丝缅怀吧！

1.1   功能和使用

TeamSource的功能：

n         允许CheckIn和CheckOut，支持文件不同版本的存放；

n         本地和远程差异的比较功能（内置一个还算方便的源代码比较工具，只是字体有些难看）；

n         有新的文件被CheckIn，可以发送邮件通知；

n         可以根据文件的扩展名过滤待处理的文件；

n         整个工程的历史日志查看（记录对服务端的动作，比如checkin，删除等操作）；

n         提供两个视图，远程和本地。通过远程视图，直接查看并访问远端服务器上文件的内容；在本底视图上，可以进行checkin、checkout、delete、remove等操作。

n         可以在远程视图中设定文件的当前使用版本；

TeamSource的部署：

n         简单方便，依赖操作系统的网络文件共享，不需要服务端；

n         各用户仅需要安装TeamSource程序，并通过设置相同的工程文件即可进行版本管理；

TeamSource的技术实现：

n         借助于网络的文件共享，并通过一个lock.dat来控制锁定；

n         文件的各个版本经过压缩存储在.z文件中；

1.2   挥泪告别

TeamSource的问题：

n         采用大锁，同一时刻仅有一个人进行checkin，不支持多个人同时分目录checkin；

n         程序不稳定，经常出现access violation的错误——这是第一大罪状！况且该系列的TeamSource已经不做升级！（好像有新的TeamSource for web/.net？但是从来没有见过）

n         不支持版本的分支（可能是我孤陋寡闻也不一定）；

n         不支持版本标签，不支持基线管理。只能依赖于时间才能将一个工程中的若干文件串在一起；

n         远程视图下：目录的include，exclude的设置无法在子目录中生效，必须手工进行设置；

n         由于目录的include以及exclude问题，容易造成文件的无法check in，即通过在本地视图中刷新但检测不到需要check in 的文件——此是第二大罪状；因此TeamSource是将第一次checkin时候的所有文件的扩展名作为include的内容，后续该目录新增其他类型文件时，不能自动检测，比如手工添加扩展名或直接增加一个*.*。

n         ……，一言难尽啊！

2       迈入CVS阵营

2.1   概述

CVS是跨平台的并行版本管理工具。部署时分为服务端和客户端。服务端支持unix,linux,windows等多个平台。在windows下，客户端是一个控制台程序。这里的WinCVS就是对cvs进行了封装之后，具有良好的用户界面的cvs客户端。

以下主要谈谈teamsource里面一些概念和功能在wincvs里面的体现，以帮助原来teamsource的使用者更快地熟悉和掌握wincvs的使用（以wincvs 1.3.17.2 beta 17 build 2为例）。

由于使用时间不长，因此以下内容必存在诸多疏漏和错误之处，请不吝指正。

2.2   使用之对比

请允许我使用teamsource使用者的惯性思维来理解cvs（惭愧的是，到目前为止，我也仅仅会使用这么点功能——虽然学到这些已经让我经历了阵痛）。

序号	类别	内容	TeamSource	WinCVS
1．	基本概念和术语	Do it和commit	Teamsource支持两阶段提交，即先对相关的文件进行标记（copy, checkin, merge, delete from local, remove from project），然后使用“do it”执行之。	Wincvs采用类似做法。对于本地文件可以有remove和add两类操作，之后进行commit。 采用update功能实现teamsource的类似功能。
2．	基本概念和术语	刷新	本地视图，refresh功能	Query Update功能
3．	操作	把本地新增的诸多目录和文件提交到服务端	在本地视图中，选择refresh；之后teamsource会在右边的“recommented changes to remote project”栏中提示待提交的文件。此时选中所有文件，点击右键check in或“do it”一次性提交。	选择所在的目录，注意将过滤器设置为查看修改和更新的状态。并将flat mode打开。此时wincvs将在指定目录中搜索符合条件的文件，并在工作区中以相应图标进行显示。 根据不同目录分批选择相关文件（当操作对象超过一个目录时，相关按钮变灰），然后”add”或“add binary”或”add unicode’进行添加。 然后一次性多选所有modified的文件，进行commit。
4．	操作	修改本地文件后，更新	在本地视图中刷新，然后选择文件，check in即可。	选择文件所在的目录，会发现该文件已经被标记为modified，此时选中文件，commit即可。
5．	操作	下载服务端的最新版本	能自动根据远端的目录结构创建本地目录。 下载服务端版本后，本地冲突的版本随即丢失（被覆盖）。	不能自动根据远端目录结构创建本地目录。需在update 操作弹出的options 窗口中打开“create missing directory …”选项。 下载服务端版本后，wincvs自动将本地变化的版本另存为带#的文件名。
6．	操作	放弃本地更改	方案一：删除本地文件，然后从服务端重新获取文件； 方案二：放弃checkin操作，将相关文件移动至“recommened changes to local project”栏中，并执行“copy”操作。	选中相关文件，执行update，在options中打开“get clean copy”选项，然后确定。 手工删除cvs自动另存的本地备份文件（选中后，按del键）。

2.3   常见问题之解决

n         Waiting for lock

可能原因：其他人正在commit过程中，强制退出？

解决办法：登录cvs服务端的计算机，进入cvsroot/cvsroot目录，删除以“#cvs.lock”，“#cvs.rfl”，“#cvs.wfl”打头的文件。不过，做这些操作前，一定要确认的确没有人在执行cvs操作，否则可能会带来不可预知的后果（来源于《cvs和Nightly Build技术》，作者：杨锦方等，清华大学出版社出版）。

n         Commit之后还是修改状态，但是命令执行的结果为0

可能原因：文件时间变化，但内容未变化

解决办法：强制checkin,在commit 窗口的option中将“force commit”打勾，如图：

n         自己是用户A，但是commit操作却提示无法使用另一个用户名通过身份验证？

可能原因：从另一个同事（用户）那里直接复制了某个目录里的文件，并且尝试commit该目录下的某个文件。由于cvs会自动在名为cvs的隐藏目录的root文件中记录用户名，因此导致登录错误。

解决办法：打开该文件所在目录的同级cvs目录（先打开windows的查看选项，设置允许查看隐藏的目录），更改root文件中的用户名和cvs所用的username一致。

n         明明本地改过的文件，确无法Add？

可能原因：其他用户在你之前刚刚commit了该文件的一个版本；

解决办法：重新update。

[文终]