1. Overview
CVS 是开放源码的一个奇迹,亦是开放源码得以延续和发展的推动者,是版本控制的经典。CVS 是常用的版本控制工具。
Starteam 是一个集合了版本控制和缺陷控制两种功能的软件,并且具有 CVS 没有的强大的图形界面,易学易用。2002年底被Borland公司收购,发展前景未知,它是我是用的第一个大型商用版本控制软件(真的付了Money的呦)。
评价 CVS、STARTEAM 孰优孰劣,是一个仁者见仁,智者见智的问题。 Starteam 的图形化界面,能够使初学者易于接收,而且其缺陷控制功能的功能(基于数据库的Change Request),是CVS 不具有的,更是相应工具中独树一帜的。 CVS的优秀跨平台能力、强大的命令行、清晰的服务器端数据结构更便于数据的备份、灾难恢复和可靠性。Simple is Butiful 送给 CVS 一定没错。 |
-
侧重不同
CVS专注于配置管理软件范畴中的版本管理系统。而配置管理系统除了包括版本管理外,还包括构建管理(Build Management)和缺陷跟踪系统。而Starteam包括了这三项。本文档也就只比较其版本管理系统的异同。
-
权限控制
一般来说,CVS的权限设置单一,通常只能通过CVSROOT/passwd, CVSROOT/readers, CVSROOT/writers 文件,同时还要设置CVS REPOS的物理目录权限来完成权限设置,无法完成复杂的权限控制;而STARTEAM无需通过物理路径的权限设置,而是通过自己的数据库管理,实现了类似WINDOWS NT的域用户管理和目录文件ACL控制。
但是CVS通过CVSROOT目录下的脚本,提供了相应功能扩充的接口,不但可以完成精细的权限控制,还能完成更加个性化的功能。
-
易用性
Starteam的图形界面功能强大,但其命令行功能较CVS弱,需要自己编写shell脚本加强。而随着WINCVS作为图形客户端的可用性的增强,Starteam的强项正在被削弱。
-
Label的管理
CVS 的 label 建立在文件上,难以确定到底有多少存在的 label ,而STARTEAM(图形界面)可以很方便知道有哪些 View Label及Revision Label。
CVS的版本分支, label是建立在文件上,工作在其他分支的程序同样会看到其它分支的label;而Starteam的label只在同一个视图内有效,有独立的命名空间。
STARTEAM具有Promotion states,可以看作是label的标签。在label上又封装一层的 Promotion State 便于记录版本的提升,和建立自动编译;而CVS 没有浮动 label 的概念,只能通过文件记录方式实现(如我们使用 .promotion 文件记录当前稳定的 label)。
-
文件缓存
Starteam 存在CACHE目录,缓存了所有 Checkout的版本的文件,因此 Checkout速度快。而CVS没有缓存,check out过程较慢,尤其是分支的 Checkout。
但我对此表示怀疑。尤其是Starteam Unix客户端基于JAVA技术,速度明显比CVS要慢。
-
操作文件名和目录名
CVS的REPOSITORY的物理存储结构即为项目的组织结构,使得文件名修改和目录的重新组织成为难题,往往需要管理员权限去手动操作Repository;而STARTEAM的Repository的文件结构和视图的文件结构可以完全不同,目录、文件名修改和移动非常方便,基于数据库的文件名管理还可以方便地在不同工程之间共享文件,协同工作。
-
CVS是程序员的工具,STARTEAM还是管理项目的工具
个人文件管理或小项目的组织,需要轻量级的管理,和灵活的文件导入、导出,以及和*代码的交互,则CVS,Perforce,PVCS,SourceSafe等面向文件的版本控制占优势。对于公司、大项目,需要独立的测试、QA等分工,还要更多的考虑多样的用户权限控制,易用性(图形界面),缺陷控制,则需要面向工程的STARTEAM来进行版本控制和开发。
-
CVS的优势
CVS的优势:项目文件可以方便的组合和移植,这是因为CVS以文件为核心,即面向文件的管理方式。而且目前网络上很多开放源码都采用CVS,可以很好沟通。
CVS配置简单、健壮、可以很容易地移植;STARTEAM集成度较高,移植过程复杂,需要的管理负担大,需要完善的备份计划。
CVS是开发源码,服务器端存储易于理解,便于控制;而Starteam为商业软件,服务器端存储方式封闭,难以管理。但是 CVS 不提供图形界面,有较长的学习曲线。
-
Starteam 的劣势
不支持分支的合并,需要过多的手动干预。而CVS可以自动完成。
速度慢,一定程度上影响开发效率。
不支持并行开发,不能很好解决Merge的问题。而CVS可以智能 Merge。
故障恢复困难,需要有专职管理员维护。而CVS易于维护。
-
评价优劣,不如先用先得
不用刻意去取舍哪一个,只要用好,即可。况且,已经有了完美的CVS、STARTEAM互相转换的方法。(参见:《CVS, Starteam互相转换》)
下面通过对 CVS、STARTEAM 的服务器端和客户端对照,了解背后的真相。
2. CVS vs. STARTEAM——服务器设置
2.1. CVS服务器设置
2.1.1. 运行 CVS
-
/etc/services
...cvspserver 2401/tcpcvspserver 2401/udp...
-
用xinetd运行: /etc/xinetd.d/cvs
service cvspserver{ socket_type = stream protocol = tcp wait = no user = root server = /usr/bin/cvs server_args = -f --allow-root=/repos/root1 --allow-root=/repos/root2 pserver disable = no}
-
用inetd运行: /etc/inetd.conf
...cvspserver stream tcp nowait root /usr/bin/cvs cvs -f --allow-root=/repos/project --allow-root=/repos/user pserver...
2.1.2. 添加帐号和设置权限
-
创建系统帐号
假设目录 /repos/project 作为多人共享项目的版本控制根目录,需要用组权限控制;/repos/user作为存放个人独占地版本控制根目录。管理员帐号为cvsroot,项目版本控制的公共帐号为 cvsproject,用户版本控制的公共帐号为 cvsuser,相应的用户组为 cvsroot, cvsproject, cvsuser。
-
创建CVS根目录
$ mkdir -p /repos/project$ mkdir -p /repos/user$ chown cvsroot:cvsroot /repos/project$ chown cvsroot:cvsroot /repos/user$ chmod 775 /repos$ chmod 2775 /repos/project$ chmod 2775 /repos/user$ su - cvsroot$ cvs -d /repos/project init$ cvs -d /repos/user init
运行完毕 cvs init 之后,在CVS根目录下创建了配置目录CVSROOT,权限如下:
$ ls -l /repos/project/CVSROOT/-r--r--r-- 1 cvsroot cvsroot 493 Jan 21 10:37 checkoutlist-r--r--r-- 1 cvsroot cvsroot 696 Jan 21 10:37 checkoutlist,v-r--r--r-- 1 cvsroot cvsroot 760 Jan 21 10:37 commitinfo-r--r--r-- 1 cvsroot cvsroot 963 Jan 21 10:37 commitinfo,v-r--r--r-- 1 cvsroot cvsroot 527 Jan 21 10:37 config-r--r--r-- 1 cvsroot cvsroot 730 Jan 21 10:37 config,v-r--r--r-- 1 cvsroot cvsroot 753 Jan 21 10:37 cvswrappers-r--r--r-- 1 cvsroot cvsroot 956 Jan 21 10:37 cvswrappers,v-r--r--r-- 1 cvsroot cvsroot 1025 Jan 21 10:37 editinfo-r--r--r-- 1 cvsroot cvsroot 1228 Jan 21 10:37 editinfo,vdrwxrwxr-x 2 cvsroot cvsroot 4096 Jan 21 10:37 Emptydir-rw-rw-rw- 1 cvsroot cvsroot 0 Jan 21 10:37 history-r--r--r-- 1 cvsroot cvsroot 1141 Jan 21 10:37 loginfo-r--r--r-- 1 cvsroot cvsroot 1344 Jan 21 10:37 loginfo,v-r--r--r-- 1 cvsroot cvsroot 1151 Jan 21 10:37 modules-r--r--r-- 1 cvsroot cvsroot 1354 Jan 21 10:37 modules,v-r--r--r-- 1 cvsroot cvsroot 564 Jan 21 10:37 notify-r--r--r-- 1 cvsroot cvsroot 767 Jan 21 10:37 notify,v-r--r--r-- 1 cvsroot cvsroot 649 Jan 21 10:37 rcsinfo-r--r--r-- 1 cvsroot cvsroot 852 Jan 21 10:37 rcsinfo,v-r--r--r-- 1 cvsroot cvsroot 879 Jan 21 10:37 taginfo-r--r--r-- 1 cvsroot cvsroot 1082 Jan 21 10:37 taginfo,v-rw-rw-rw- 1 cvsroot cvsroot 0 Jan 21 10:37 val-tags-r--r--r-- 1 cvsroot cvsroot 1026 Jan 21 10:37 verifymsg-r--r--r-- 1 cvsroot cvsroot 1229 Jan 21 10:37 verifymsg,v
可以看出文件 history, val-tags 的权限是任何人可读写,其它文件的权限是任何帐号只读。
文件 CVSROOT/val-tags 用来确定是否一个TAG是可用的;文件 CVSROOT/history 用来记录CVS的访问记录。
-
创建 CVS 用户帐号
使用系统帐号不安全,而CVS提供了独立于系统的用户帐号管理。
使用配置文件 CVSROOT/passwd, CVSROOT/passwd, CVSROOT/passwd ,来管理帐号。
2.1.3. 创建工程
只能以 cvsroot 用户创建工程。因为 cvs 根目录的权限设置为 cvsroot 帐户可写。
-
在客户端创建工程
于是创建了多用户共享的工程 test。
-
另一种创建工程的方法:在服务器端创建工程
可以直接在服务器端创建目录,设置权限,即完成工程的创建。当然这样创建的工程只是一个空的工程,需要在客户端为空的工程逐个添加文件和目录。
$ cat /repos/project/CVSROOT/passwdjiangxroot:_passwd_here_:cvsrootanonymous:_passwd_here_:cvsuserjiangxin:_passwd_here_:cvs_jiangxinjohnson:_passwd_here_:cvs_johnson$ cd /repos/project$ mkdir jiangxin; chown -R cvs_jiangxin:cvsuser jiangxin; chmod -R 2700 jiangxin$ mkdir johnson; chown -R cvs_johnson:cvsuser johnson; chmod -R 2700 johnson
于是创建了两个用户独占的工程。
2.1.4. 用CVS管理文件进行功能扩充
确省安装的CVS的权限仅仅作用于目录,而不能精细到文件级别。而且即使用户只需要拥有文件的只读权限,也要对相应的目录具有写权限,因为需要在目录下创建锁定文件。有一个办法可以避免此问题,即:通过配置文件 CVSROOT/config 的 LockDir 来设置单独的锁定目录,为该单独的锁定目录设置更宽泛的权限控制。
CVS 提供了功能的扩充接口:CVSROOT目录下的管理文件。这些文件提供了相应功能扩充的接口,不但可以完成精细的权限控制,还能完成更加个性化的功能。关于CVSROOT下的脚本,FreeBSD 的源代码就有一个非常好的CVSROOT脚本,可供我们参照:
Setting up a CVS repository - the FreeBSD way。我们可以参照这个指南,定制我们自己的CVSROOT脚本。
下载 FreeBSD 的 CVSROOT 脚本,可以以匿名用户连接到 FreeBSD 的 CVS 服务器:
$ cvs -d :pserver:anoncvs@anoncvs.freebsd.org:2401/home/ncvs login # 输入密码 anoncvs$ cvs -d :pserver:anoncvs@anoncvs.freebsd.org:2401/home/ncvs co CVSROOT-src |
下载获得 FreeBSD 的 CVSROOT 代码后,需要进行相应的定制,然后才能 checkin 到自己的 CVSROOT 目录中。这个补丁是我对其的修改和定制:patch.txt。
定制过程:
-
升级CVS
确认安装的CVS服务器版本,要高于 1.11.2 。因为我们要用到在版本 1.11.2 才出现的功能:能够在检查commit log 后重新读入 commit log,以实现对 commit log 的格式化。
-
定制 PERL 模块 cfg.pm
文件 CVSROOT/cfg.pm,是 perl脚本的核心包,对其做了一些改动,主要是添加了禁止某些用户发送 Email功能;还增加了部分子过程,部分是从原 log_acum.pl 中移动过来,目的将这些函数设置为模块内部的函数便于其它需要发送邮件的脚本调用,如脚本 log_accum.pl 和 tagcheck 都需要使用这些新增子过程。
对脚本 CVSROOT/cfg.pm 的改动如下:
还在该perl模块中增加了几个过程,供其它程序调用。
文件 CVSROOT/cfg_local.pm 用于对模块 cfg.pm 进行定制:
- 设置为0,不强制文件头包含特定的CVS关键字。
- 设置安装的CVS服务器的最低版本为 1.11.2;
- 创建目录的事件,也发送邮件。参见脚本: CVSROOT/log_accum.pl。
- 注释该函数,不检查用户组。
- 定制该数组,将 CVS 模块的 commit log 存储在对应的文件中。
- 添加哈希表 @MAIL_MAP,设置模块和用户邮件地址的对应关系,相应模块的 commit,通过邮件通知相应用户。
- 添加哈希表 @TAG_MAP,设置某些格式的TAG只能被某些用户管理。
- 确省的邮件地址。对于没有在 MAIL_MAP 数组找到匹配的邮件地址,即使用该地址。确省为 'nobody'。
-
CVS 服务器配置文件:CVSROOT/config
#SystemAuth=no #LockDir=/var/lock/cvs #TopLevelAdmin=noLogHistory=TOFEWGCMAR RereadLogAfterVerify=always
-
设置版本控制过程中,需要忽略的文件。这些文件将不被显示为未知状态("?")。如:
*.db*.info*.[Sp]o*.core*.aps*.clw*.exe*.ncb*.obj*.opt*.plgDebugRelease
亦可由每个目录下的文件 .cvsignore 来控制;
对于 WinCVS,则由文件 C:/.cvsignore 来控制,如果将 HOME 路径设置为 C:/ 的话。
-
匹配文件名,并作相应处理。如: -kb 即以二进制方式处理文件。
*.gif -k 'b'*.GIF -k 'b'*.jpg -k 'b'...
-
设置数据仓库中的模块名,可以通过命令:“cvs co -c”察看当前数据仓库(repository)中包含的模块/工程名称。也可以在调整服务器端目录结构时,设置 modules 来保持和以前设置的兼容性。
CVSROOTCVSROOTmodule1module2 &module3
-
列在 checkoutlist 中的文件,在 checkin 后,能够自动在服务器 CVSROOT 目录中重建。
#access availcfg.pmcfg_local.pmcommit_prep.plcommitcheckcvs_acls.plexcludelog_accum.pllogcheckoptionsrcstemplatetagcheckunwrapwrap
-
当用户设置了 watch 一个文件,可以定制该文件进行控制。在此该文件未被用到。
-
Commit 事件要触发三个脚本文件,依次是 commitinfo, verifymsg, loginfo。其中先遍历整个目录树对所有需要 commit 的文件执行 commitinfo文件。再分别针对每一个目录执行 verifymsg, loginfo 脚本。
commitinfo 会调用 commitcheck 脚本,完成的功能:通过用户主机名、用户名来检查权限;确认CVS服务器的版本号不低于某个版本;将遍历目录树的结果(最后一个目录名)记录下来,以便接下来运行 verifymsg, loginfo的脚本能够确认运行结束等。
相关文件:CVSROOT/commitcheck,CVSROOT/cvs_acls.pl,CVSROOT/avail,CVSROOT/commit_prep.pl,CVSROOT/exclude,CVSROOT/cfg.pm,CVSROOT/cfg_local.pm。
文件 CVSROOT/avail,被脚本 cvs_acls.pl 读取,再被脚本 commitcheck 调用,用以精细控制权限。例如:
group|meisters|peter,jdp,markm,joe# Pick up the list of bad users from ncvs/CVSROOT/badcommitters See that# file for detailsgroup|penaltybox|!badcommittersunavailavail||CVSROOTavail||distribavail||docavail||portsavail||srcunavail||src/contrib/binutils,src/contrib/fileavail|obrien|src/contrib/binutils,src/contrib/fileunavail||src/contrib/tcpdumpavail|fenner,nectar|src/contrib/tcpdumpavail||wwwavail|:meistersunavail|:penaltybox
-
用于检查和格式化 commit log。禁止在版本控制提交时,使用空的 commit log。对于 wincvs 在用户不提交 commit log 时,会自动使用“no message”作为commit log。为了禁止该情况发生,需要定制该脚本:
相关文件:CVSROOT/logcheck。
-
将 commit log 分门别类存储在目录 CVSROOT/commitlogs 下,并同时通过邮件外发。为了防止一次事件触发多次的邮件外发,该脚本利用到 commitinfo 的运行结果,只有确认到了目录树的最后,才发送邮件。 模块和存储日志文件以及用户邮件列表在文件CVSROOT/cfg_local.pm中定义。
相关文件:CVSROOT/log_accum.pl,CVSROOT/cfg.pm ,CVSROOT/cfg_local.pm。
文件 CVSROOT/loginfo,调用脚本 log_accum.pl,并传递文件名等参数,用于组织日志和发送邮件。
原 FreeBSD 脚本存在一个 BUG,如果文件名或者目录名中存在空格,脚本运行不正常,出错,导致不能组织和发送邮件,这个 Bug 修正方法如下:
在文件 CVSROOT/loginfo中调用 log_accum.pl 时使用的参数由原来的 %s 修改为 %{,,,s},即加入三个连续的逗号作为分隔符,否则使用空格作为分隔符,难以区分是文件的分隔符还是路径或文件名中的空格。
bash$ tail -1 loginfoDEFAULT $CVSROOT/CVSROOT/log_accum.pl %{,,,s}
对文件 CVSROOT/log_accum.pl 的修正如下:
-
在执行 tag/rtag 命令前执行该脚本,如果脚本返回非零值,tag/rtag 动作取消。相关脚本:CVSROOT/tagcheck。负责对添加/删除 TAG 事件进行控制——允许/禁止/发送邮件。
由于 tag/rtag 事件不象 commit 事件,不是通过多个脚本的配合完成,而是只通过一个脚本 taginfo 完成。这就出现一个问题:如果为一个目录树打上TAG,则可能多次执行脚本,可能要多次触发邮件发送。我的解决办法是,根据TAG进程的 PID 确定在整个过程唯一的文件名,将日志记录到该文件中,taginfo 脚本本身无法知道是否结束,而是系统通过 crontab 定期执行脚本 CVSROOT/checkmailspool.sh来检查是否有完成的 tag 邮件需要外发。
文件 CVSROOT/checkmailspool.sh,加入到 crontab 中定期执行,检查 tagcheck 生成的邮件。
#!/bin/sh# checkmailspool.sh# Auther: Jiang Xin## $CVSMAILPATH (cvs mail spool) is a spool directory created by user, # and cvs tag message will store in it.# run this script timely to check cvsmail spool and send messages...# please put this script in crontab. CVSMAILPATH=/var/spool/cvsmailif [ ! -d $CVSMAILPATH ]; thenmkdir -p $CVSMAILPATHchmod 777 $CVSMAILPATHficd $CVSMAILPATHfor i in `ls `; dopid=`echo $i| sed -e "s/.*/./([0-9]*/)$//1/"`xxx=0while ps -p $pid>/dev/null; doxxx=`expr $xxx + 1`if [ $xxx -gt 10 ]; thenbreakfisleep 3echo waiting $pid, $xxx times ...doneecho -e "/n/n========================================" >> $iecho -e "End/n" >> $icat $i | sendmail -oi -oem -odb -trm -f $idone
-
清除CVSROOT产生的临时文件
以上 CVSROOT 脚步在执行过程中将会在临时目录中产生很多临时文件,如果不加以清理,不但会浪费磁盘空间,更有可能导致发送张冠李戴的错误邮件。在 crontab 中配置每隔一个小时执行一遍以下脚本:
#/bin/shcd /tmpls /#cvs.files.* | sed -e 's//#cvs.files./([0-9]*/)/..*$//1/g' | sort -u | /while read xxx; do if ps --pid $xxx>/dev/null 2>&1; then continue; fi ; / rm -f /tmp//#cvs.files.$xxx.* ; done
2.2. Starteam服务器权限设置
每一个服务器配置一个独立的用户数据库设置。用户的权限设置灵活,和本机帐号设置无关(不用设置本地帐号),且和本地路径无关。
2.2.1. 用户管理
如果使能了Lockout功能,则需要建立两个系统管理员帐号,以防止一个被锁定(如多次错误登录被无限期死锁),能用另外一个解锁。
-
建组原则(假设组名为 team1)
-
建立用户组和子组
假设组名为 team1,首先建立一个大组 ga_team1 组;再在 team1 组下再建立三个child group: g_team1_admin 组,g_team1_users 组和 g_team1_rdonly 组(即只读组)。
-
建组的考虑
将权限分配到组,是管理权限的基本原则。因为 starteam 在赋予权限时,是将用户名和组名混在一起,因此为组名加上前缀 “g_” 或者 “ga_”。区分 g_ 和 ga_ 是因为要防止误将权限设置到更大的 ga_ 组中(如后所述)。
组管理员属于 g_team1_admin 组,拥有管理 LABEL 权限,创建新视图,以及管理代码权限分配权限;starteam管理员部分授权,目的是减少starteam管理员的管理负担。提高效率。
小组的其它用户属于 g_team1_users 组,除了不具有 g_team1_admin 组的管理权限外,其它权限同 g_team1_admin。
对于其它有研读代码或者掌握进度需求的用户,如 QA、部门领导等属于 g_team1_rdonly 组,除了具有只读方式看代码权限外,其它同 all users。
建立项目组 ga_project_manager,是独立于项目组(也可以考虑为每个项目组单独设置),进行项目管理。为管理需求变更,在其下建立 g_pm_req;为管理TODO LIST,建立 g_pm_todo组。
分配权限时,要注意不要把权限赋予大组(如 ga_team1 组)。因为 team1 组包括了 g_team1_rdonly 组(只读用户组)!
-
关于组本身的权限
除 Administrators 组外,任何组不要设置组的权限,以免组的权限设置超越了项目的安全设置,使对项目的安全设置形同虚设。
-
-
在UNIX命令行上进行代码的check in/check out,需要建立独立用户,如:team1_release。以免由于使用同一个用户名在不同工作站check代码,造成文件状态UNKNOWS的情况。参见Starteam Howto中关于文件状态unknown的FAQ。
2.2.2. 服务器配置的安全设置
-
Starteam VTS 的启动方式设置为NT服务方式
保证服务器重启后,Starteam自动启动。
-
Starteam 服务器端配置
-
General
设置登录超时60秒,未动作超时300分钟。
-
Audits
设置只保留10天安全日志。
-
Vault
设置不清除文件状态表;
设置最大CACHE为400MB。
设置Cache的文件夹在Valut文件夹之外,以使在备份时,对cache区别对待(不备份Cache)。
-
Notifications
使能Email通知。
-
Protocal
只保留一种协议支持:TCP/IP(SOCKETS),因为别的协议支持有问题;
TCP/IP加密级别:不作设置,但是管理员要通知用户,如果客户端支持传输加密,请至少选择RSA R4 stream加密。windows客户端都支持,但是unix命令行不支持。
-
-
访问权限(Access Rights)
管理员完全权限,不赋予其它用户任何权限。
-
系统策略(System Policy)
-
Access Rights
使能 Ignore object ownership, 即忽略OwnerShip,一切均按照权限设置。
不选择 Ignore group privileges, 即在保证只有 Administrators 组设置了组权限情况下,允许Administrators组用户超越项目的权限限制实施管理。
-
Security Events
设置只保留30天的安全日值。
-
Passwords
设置密钥最小长度6个字符。
在用户管理(User manager)界面,设置所有用户第一次登录必须修改口令,并且不允许设置空口令。
-
Logon Failures
设置5次失败登录锁定帐号,帐号锁定5分钟。
-
2.2.3. 工程的权限设置
先打开要配置的工程,Project->Access Rights,来设置工程权限。
-
Project
-
All Users
设置所有用户(All Users)具有如下权限:
See Project and Properties
-
g_xxx_admin
设置组管理员(如:g_team1_admin 组)具有如下权限:
赋予除了 Delete project 外所有权限。以便于管理员修改自身权限,给自己加上删除label权限等,但要注意缺省没有赋予管理员的权限,当管理员完成相应管理功能后,恢复原状。
不能赋给任何人删除工程权限!因为工程删除不可逆。
-
-
Views
-
All Users
设置所有用户(All Users)具有如下权限:
See View and its Properties
-
g_xxx_admin
设置组管理员(如:g_team1_admin 组)具有如下权限:
赋予除了 Delete View, Delete Labels 外所有权限。
Delete View, Delete Labels 不可逆,因此不赋予任何人此权限。但为了减轻管理员负担,赋予了 g_team1_admin 组 change view security setting 权限,g_team1_admin可以修改自己权限,使具有删除 label, 甚至是删除 view 权限,但要注意完成维护功能后,立即去掉该两项权限!
-
-
Child Folders
-
g_team1_rdonly 组
设置只读组(如:g_team1_rdonly 组)具有如下权限:
具有:See folder and its properties, See folder history, See folder links 权限。
-
g_team1_users 组
设置普通用户组(g_team1_users 组)具有如下权限:
除 Modify folder properties, Delete folder from parent folder, Change folder security set 外所有权限。
-
g_team1_admin组
设置组管理员(如:g_team1_admin 组)具有如下权限:
除了 Delete folder from parent folder 外所有权限。
-
-
Files
-
g_team1_rdonly 组
设置只读组(如:g_team1_rdonly 组)具有如下权限:
具有:See file and its properties, See file history, See file links, Check out files 权限。
-
g_team1_users 组
设置普通用户组(g_team1_users 组)具有如下权限:
除 Change file security set 外所有权限。
-
g_team1_admin 组
设置组管理员(如:g_team1_admin 组)具有如下权限:
所有权限。
Move folder out of a view or project 权限也是危险操作,文件移出视图,也从历史视图中去掉,可能会破坏完整性。但将文件或目录移动到另外一个视图,是从服务器端删除文件的唯一办法。因此慎用。
-
-
Change Request
-
All Users
添加所有用户(All Users),将权限设置为空。即默认禁止一切的策略。
工程的权限设置中的ChildFolders, Files, Change request 等的权限设置,用来确定工程的默认设置。即为没有对各项进行单独权限设置时的默认安全设置。
将 Change Request 定义为默认禁止一切,目的是只在指定目录添加 Change Request.
-
-
Topics
-
All Users
设置所有用户(All Users)具有如下权限:
设置除了 “Change topic security set”,“Delete Topic from folder”外所有权限。提供用户通过 TOPIC 进行讨论以及保存备忘。
设置组管理员(如:g_team1_admin 组)具有所有权限。
-
2.2.4. 视图的权限设置
先打开要配置的视图,View->Access Rights,来设置视图权限。
-
根视图
可以不设置权限,继承整个工程中的Project AccessRight的 Views 的各项权限设置。
-
分支视图
按需设置。可以使老版本的维护由其他人完成,或者进行 xp 模式开发,为开发者(非管理员)设置更大的权限。
2.2.5. 文件夹的权限设置
选择视图下相应文件夹,鼠标右键单击,选择 Advanced->Access Rights,设置权限。
需要先设置“根目录”权限。再单独设置各一级子目录(defect, src, doc等)的权限。如果需要还可以对二级目录等(模块)设置权限,但不建议设置二级目录的权限。
-
根目录
根目录和子目录在权限设置上的异同
根目录的权限不传递,即在根目录上设置的权限对派生的子视图没有影响;而非根目录会传递权限,所以尽量不要在子目录(非根目录)上设置权限,以免连带影响其它视图中该目录的权限,造成混乱。
根目录继承视图或者工程的 Child Folder 权限;子目录先继承根目录权限,再继承视图,工程权限。
因此,不要设置根目录的权限页的 Child Folder 页,这样没有设置权限的子目录便可以继承视图的 Child Folder页的权限。但是可能需要设置根目录权限页的 This Folder 页,因为 This Folder的权限默认取自视图或者工程的 Child Folder 设置。如果有子目录的权限大于视图或者工程的 Child Folder的设置,就需要设置This Folder 设置。但是副作用是,子目录的权限并没有完全继承视图或者工程的更严格的设置,而是采用了根目录的 This Folder 设置和 视图的Subfolder设置的组合(因为根目录没有设置Subfolder权限)。这样有可能使所有能够访问根目录的用户访问整个目录树!!!好像没有更好的解决方案。
根目录上的权限设置:
-
This Folder
All Users:所有用户(All Users)具有 See folder and its properties, See folder history, See folder links 权限。
g_team1_admin: 组管理员(g_team1_admin)具有:除了Delete folder from parent folder 外所有权限。
-
Child Folders,Files, Change Requests, Tasks, Topics
不作设置,以继承视图或者工程的权限设置。
-
Defect目录
-
This Folder
All Users : 所有用户(All Users)具有—— See folder and its properties, See folder history, See folder links 权限。
g_qa_admin:QA组管理员(g_qa_admin)具有——除了Delete folder from parent folder 外所有权限。
g_team1_admin:team1组管理员(g_team1_admin)具有——除了Delete folder from parent folder 外所有权限。
设置服务QA管理员和team1目录管理权限,允许QA管理员建立子目录,用于对CR分类。
-
Child Folders
All Users:所有用户(All Users)具有——See folder and its properties, See folder history, See folder links 权限。
g_qa_admin:QA组管理员(g_qa_admin)具有——除了Delete folder from parent folder 外所有权限。
g_team1_admin:team1组管理员(g_team1_admin)具有——除了Delete folder from parent folder 外所有权限。
-
Change Requests
All Users:所有用户(All Users)具有——除了Change CR Security set , Delete CR from folder外所有权限。
g_qa_admin:QA组管理员(g_qa_admin)具有——除了Delete CR from folder 外所有权限。
为了减轻管理员负担,赋予了 g_qa_admin 组 change CR security setting 权限,g_qa_admin可以修改change request的权限,使之可以被删除,再删除该 cr。
-
Files, Tasks, Topics
不另外设置权限,继承视图或者工程的权限。
-
-
src 目录
src 目录是用来存放源代码的目录,应着重注意本目录权限设置。
可以不作任何单独设置,因为继承了视图或者工程的权限设置。如果工程或者视图关于文件的权限设置足够安全的话,可以不必设置本目录权限。
-
ProjectManagement 目录
ProjectManagement 目录,用于以文件和 TOPIC形式存储 TODO_LIST, 编程规范,需求变更。
-
ProjectManagement 目录
-
This Folder
All Users :所有用户具有—— See folder and its properties, See folder history, See folder links 权限。
ga_project_manager 组 :具有——除 Modify folder properties, Delete folder from parent folder, Change folder security set 外所有权限。
g_team1_admin组 :具有——除 Delete folder from parent folder 外所有权限。
-
Child Folders
All Users :所有用户具有—— See folder and its properties, See folder history, See folder links 权限。
ga_project_manager 组 :具有——除 Modify folder properties, Delete folder from parent folder, Change folder security set 外所有权限。
g_team1_admin组 :具有——除 Delete folder from parent folder 外所有权限。
-
Files
All Users:具有——See file and its properties, See file history, See file links, Check out files 权限。
ga_project_manager:普通用户组具有——除了 Change file security set, Delete file from folder 外的所有权限。
g_team1_admin:组管理员具有——除了 Delete file from folder 外的所有权限。
-
Topic
All Users:具有——除了 Change top security set, Delete topic from forder 外所有权限。
g_team1_admin:具有——除了 Delete topic from forder 外所有权限。
-
Change
暂不设置,采用工程缺省禁用配置。
-
-
TODO LIST子目录
所有用户具有只读文件,读写TOPIC权限;g_pm_todo 组 和 g_team1_admin组具有读写文件,读写topic,和整理目录权限。
-
编程规范
所有用户都有整理目录,读写topic权限;g_team1_admin 多了一项管理文件的权限。
-
需求变更
所有用户具有只读文件,只读TOPIC权限;g_pm_req 组 和 g_team1_admin 组具有读写文件,读写topic,和整理目录权限。
-
2.2.6. Starteam服务器优化
2.2.6.1. 提高数据库性能
数据库可以有多种选择,但是ACCESS基本可以满足需求,虽然有1.2G文件大小限制,但一般应用不会超过。数据库的选择不是性能瓶颈。
安装和使用 Copy Indexes Tools in "StarTeam VirtualTeam Server 4.0/Tuning Scripts/MS Access/Package"。
压缩数据库;(ODBCàsystem dsn)
增加数据库的Max Buffer size从2048至8192,Threads 从3至 24。
2.2.6.2. 提高Starteam服务器性能
增加Cache目录文件大小至400M;
将文件状态表导出时间从180天减少到30天;
将审计导出时间从不导出更改为30天导出;
在客户端设置Allow check out of deltas "Tools | Workstation | Files "Optimize for slow connection.""
参见http://devforum.starbase.com/starbase/Articles/Default.asp?id=206
2.2.6.3. 备份
备份涉及到:
-
The Configuration and cipher files
Configuration/server.scg
Configuration/server.cph
-
Database files
Database/StarTeamDB.mdb (Assuming Access database)
-
Vault:
Archive dir: *.*
Attachments dir: *.*
-
Optional
Cache dir: *.*
参见http://devforum.starbase.com/starbase/Articles/Default.asp?id=133
3. CVS vs. STARTEAM——服务器端存储
3.1. CVS 服务器端存储
$ pwd/repos/local$ ls -ltotal 0drwxr-xr-x 3 Administ None 0 Dec 14 20:59 CVSROOTdrwxr-xr-x 12 Administ None 0 Dec 29 21:47 worldhello$ ls CVSROOT Emptydir commitinfo,v cvswrappers,v loginfo notify rcsinfo,v val-tagscheckoutlist config editinfo loginfo,v notify,v readers verifymsgcheckoutlist,v config,v editinfo,v modules passwd taginfo verifymsg,vcommitinfo cvswrappers history modules,v rcsinfo taginfo,v$ cd worldhello$ ls -Fbio/ docbook/ html/ inc/ life/ resource/ utility/daily,v favorite/ images/ index.html,v make,v sports/$ head index.html,vhead 1.1;branch 1.1.1;access ;symbols start:1.1.1.1 jiangxin:1.1.1;locks ; strict;comment @# @;1.1date 2002.12.29.13.47.00; author jiangxin; state Exp; |
可以看出CVS的服务器端存储和客户端的是一一对应的,树形的文件系统。
3.2. Starteam 服务器端存储
以下的示意,是在 Win2k 平台,在 cygwin 命令行下输出 |
Starteam 的数据库
$ pwd/d/.repos/STARTEAM/johnson/Database$ ls -l-rw-r--r-- 1 Administ None 2101248 Sep 5 20:22 StarTeamDB.mdb |
版本控制文件
$ pwd/d/.repos/STARTEAM/johnson/Vault/Archive$ ls -F00000000 00000006 0000000C 00000012 00000018 0000001E 00000024 0000002A00000001 00000007 0000000D 00000013 00000019 0000001F 00000025 0000002B00000002 00000008 0000000E 00000014 0000001A 00000020 0000002600000003 00000009 0000000F 00000015 0000001B 00000021 0000002700000004 0000000A 00000010 00000016 0000001C 00000022 0000002800000005 0000000B 00000011 00000017 0000001D 00000023 00000029 |
缓存
$ pwd/d/.repos/STARTEAM/CACHE/johnson$ ls -F00000000.1 00000001.3 00000007.1 00000011.1 0000001B.1 00000025.100000000.2 00000001.4 00000008.1 00000012.1 0000001C.1 00000026.100000000.3 00000001.5 00000009.1 00000013.1 0000001D.1 00000027.100000000.4 00000001.6 0000000A.1 00000014.1 0000001E.1 00000028.100000000.5 00000002.1 0000000B.1 00000015.1 0000001F.1 00000029.100000000.6 00000002.2 0000000C.1 00000016.1 00000020.1 0000002A.100000000.7 00000003.1 0000000D.1 00000017.1 00000021.1 0000002B.100000000.8 00000004.1 0000000E.1 00000018.1 00000022.100000001.1 00000005.1 0000000F.1 00000019.1 00000023.100000001.2 00000006.1 00000010.1 0000001A.1 00000024.1 |
可以看出Starteam的服务器端存储和客户端完全不同,服务器端文件存储结构是平面结构。文件名和实际物理存储的对应是通过数据库来实现的。
4. CVS vs. STARTEAM——客户端设置
4.1. CVS 客户端设置
-
设置 CVSROOT 环境变量 或者命令行中指定
# 如: export CVSROOT=:pserver:jiangxin@10.0.0.152:/home/repos-user# 或者: cvs -d :pserver:jiangxin@10.0.0.152:/home/repos-user login
以下的 cvs 命令行示意,都假定已经设置了环境变量 CVSROOT。
-
登录,将密码记录在本地
cvs login# 则口令自动保存在 $HOME/.cvspass 中# cat $HOME/.cvspass:pserver:releng@10.0.0.61:/lt/repos xxxx:pserver:yzw@10.0.0.61:/lt/repos xxxxx:pserver:yzw@10.0.0.152:/home/repos-user xxx:pserver:jiangxin@10.0.0.61:/repos/home xxxxxx:pserver:jiangxin@10.0.0.152:/home/repos-user xxxxx:pserver:anonymous@10.0.0.152:/home/repos-user xxxxx:pserver:anoncvs@anoncvs1.ca.openbsd.org:/cvs xxxxxx:pserver:anoncvs@anoncvs.FreeBSD.org:/home/ncvs xxxxxxxxx
-
查看 CVS 中现有的模块
cvs co -c
# cvs -d :pserver:jiangxin@10.0.0.152:/home/repos-user co -cCVSROOT CVSROOTall-in-one pub/docbookjohnson -a jiangxinwuzj wuzj &docbook/ltfw_changes
-
将模块 Checkout 到本地
# cvs -d :pserver:jiangxin@10.0.0.152:/home/repos-user co -d johnson_homepage jiangxin
将:pserver:jiangxin@10.0.0.152:/home/repos-user中的模块 jiangxin CHECKOUT 到本地 johnson_homepage 目录。
-
本地配置文件
CVS 通过在本地源码目录同时保存配置信息(CVS目录)来记录源文件的版本等
# pwd/home/jiangxin/work/johnson_homepage# ls -l CVStotal 14-rw-r--r-- 1 root jiangxin 4786 Sep 5 10:32 Entries-rw-r--r-- 1 root jiangxin 9 Jul 23 10:01 Repository-rw-r--r-- 1 root jiangxin 43 Jul 23 10:01 Root# cat CVS/Repository jiangxin# cat CVS/Root :pserver:jiangxin@10.0.0.152:/home/repos-user
4.2. Starteam 客户端设置
下面以我们自己,(最早由杨致伟封装,后经 Johnson 改写),封装的 Starteam 命令行 Wrapper 为例作以介绍:
-
用 st config 进行配置
# cd /home/jiangxin/work/src/project# mkdir branch1# cd branch1# pwd/home/jiangxin/work/src/project/branch1# st configStarTeam ConfigurationOriginal starteam server is 10.0.0.60new server:[10.0.0.60]Original starteam server port is 49201new server port:[49201]original username is new username:[]jiangxinPassword:[********]Confirm :[********]Original checkout project is projectProject you want to checkout:[project]Original checkout view is ("/" means root view)View you want to checkout:[]branch_2_4Original checkout folder is ("/" means root folder)Folder you want to checkout:[]DevelopmentWorking dir is /usr/home/jiangxin/work/src/project/branch1Your working directory:[/usr/home/jiangxin/work/src/project/branch1]Sticky tag base on date : ("/" means not exist)Date:[]Sticky tag base on label : ("/" means not exist)Label:[]Sticky tag base on promotion-state : ("/" means not exist)Promotion-state:[]# cat .starteam.ini # StarTeam Configuration: /usr/home/jiangxin/work/src/project/branch1/.starteam.ini# /usr/home/jiangxin/work/src/project/branch1/.starteam.iniSTUSER="jiangxin"STSERVER="10.0.0.60"STPORT="49201"STPROJECT="project"STVIEW="branch_2_4"STFOLDER="Development"STCFGD=""STCFGL=""STCFGP=""STWORKROOT="/usr/home/jiangxin/work/src/project/branch1"
-
用户登录口令保存在用户主目录下
用 st config 配置完成,或者用命令 st login 登录后,用户口令自动保存在 $HOME/.stpass 中
# cat $HOME/.stpassreleng:10.1.1.60:49201:xxxxxxxxxxxxxxxxjiangxin:10.1.1.60:49201:xxxxxxxjiangxin:10.0.0.6:49201:xxxxxxxx
-
将代码 Checkout 到本地
# pwd/home/jiangxin/work/src/project/branch1# st coFolder: Development (working dir: /usr/home/jiangxin/work/src/project/branch1)Makefile: checked out.......
将配置文件 .starteam.ini 文件指定的视图下的文件,Checkout 到本地
如果不想将全部模块 Checkout 到本地,可先运行命令 st cd ,将整个目录结构 Checkout 到本地,然后再运行 st co directory,只 checkout 该目录。
-
本地配置文件
STARTEAM 不是像 CVS 那样,在本地源码目录同时保存配置信息(CVS目录)来记录源文件的版本等,而是直接保存在服务器的数据库中。而该数据库通过主机ID,来区分不同/相同用户在同一/不同主机中 CHECKOUT 文件的路径等信息。
命令行用 $HOME/.starteam 保存主机ID等配置信息。图形界面类似。
starteam cli wrapper 另外需要配置文件: .starteam.ini,因为命令行没有提供简单的读取服务器端数据库的方法。
-
5. CVS vs. STARTEAM——常用版本控制操作
表格 1. CVS, Starteam 常用命令比较
CVS 命令 Starteam 命令 说明 cvs co -D "2002-09-2 20:05" ltfilter st co --cfgd "12/29/97 10:52 AM" * Checkout 某一时刻前的代码 cvs up -l st up -l 只更本目录下文件,不更新子目录 cvs up -A st up -A 更新为最新的代码,对于cvs, 如果是分支视图,要用" -r <分支TAG> " cvs up -r st up -r Checkout 某一 tag/label 的代码 cvs ci -m "commit log..." st ci -m "commit log..." Checkin 文件 st ci -m "commit log..." --filter m Checkin 状态为 Modified 的文件 cvs add -kb
cvs commit -m "file add log... ..."
st add 添加新文件 cvs remove
cvs commit -m "file remove log... ..."
st delete-local
(删除本地文件) st remove-repos
(删除服务器文件) 删除文件 cvs diff -c -r 1.5 -r 1.7 st diff -r 1.5 -r 1.7 比较文件 1.5 和 1.7 版本的区别 cvs status -v 查看当前的 label cvs log | more st log | more 查看commit logs. cvs -n up -l st list -l 显示当前目录文件状态 cvs co -c 显示模块/工程名 cvs rtag [ -r ] st new-viewlabel --label
st label --label
为模块打 tag/label cvs rtag -b [ -r ] 图形界面 建立分支 cvs -d :pserver:jiangxin@10.0.0.217:/repos init st new-viewlabel --label
st label --label
为模块打 tag/label cd wdir
cvs import -m "Imported sources" yoyodyne/rdir yoyo start
建立新工程 -
6. CVS vs. STARTEAM——模块间共享
6.1. CVS 中的文件和目录的共享
客户端通过本地配置文件(CVS目录中的文件),来记录存储信息,因此可以在客户端的一个目录树下,维护多个工程、不同分支代码,甚至是不同CVS服务器的代码。
还可以通过服务器端配置文件:CVSROOT/modules,来将不同目录、文件组合成单独的模块,免除了客户端在一个目录树下多次 Check 不同目录的繁琐。
如下两个方式Check代码等同,但显然第一种方式好。
方式一: 通过服务器端的 modules 配置文件控制
# cvs -d :pserver:jiangxin@10.0.0.152:/home/repos-user co CVSROOT# cd CVSROOT# vi modules######## modify modules file as the follows:johnson_homepage jiangxin/web &docbook/project &docbook/nightlybuild / &docbook/pm_fw_plan_2_4 &docbook/steam_trans / &docbook/docbook_howto &docbook/pgp &docbook/program_rules / &docbook/tip_sysconfig &docbook/images &docbook/pm_fw_diary_2_4 / &docbook/rd_hwenv &docbook/steam_admin &docbook/tip_sysinstall / &docbook/lession_scm &docbook/pm_fw_module_debug / &docbook/steam_howto# cvs -d :pserver:jiangxin@10.0.0.152:/home/repos-user co -c# 显示服务器端配置文件 modules 的内容# cvs -d :pserver:jiangxin@10.0.0.152:/home/repos-user co -d web johnson_homepage# Checkout 代码
方式二: 通过在客户端,在目录树下不同的目录执行不同的 Checkout 动作实现。
# cvs -d :pserver:jiangxin@10.0.0.152:/home/repos-user co -d web jiangxin/web# cd web# ls# mkdir docbook# cd docbook# cvs -d :pserver:jiangxin@10.0.0.152:/home/repos-user co -d project docbook/project# cvs -d :pserver:jiangxin@10.0.0.152:/home/repos-user co -d nightlybuild docbook/nightlybuild# cvs -d :pserver:jiangxin@10.0.0.152:/home/repos-user co -d pm_fw_plan_2_4 docbook/pm_fw_plan_2_4# cvs -d :pserver:jiangxin@10.0.0.152:/home/repos-user co -d steam_trans docbook/steam_trans# cvs -d :pserver:jiangxin@10.0.0.152:/home/repos-user co -d docbook_howto docbook/docbook_howto# cvs -d :pserver:jiangxin@10.0.0.152:/home/repos-user co -d pgp docbook/pgp# cvs -d :pserver:jiangxin@10.0.0.152:/home/repos-user co -d program_rules docbook/program_rules# cvs -d :pserver:jiangxin@10.0.0.152:/home/repos-user co -d tip_sysconfig docbook/tip_sysconfig# cvs -d :pserver:jiangxin@10.0.0.152:/home/repos-user co -d images docbook/images# cvs -d :pserver:jiangxin@10.0.0.152:/home/repos-user co -d pm_fw_diary_2_4 docbook/pm_fw_diary_2_4# cvs -d :pserver:jiangxin@10.0.0.152:/home/repos-user co -d rd_hwenv docbook/rd_hwenv# cvs -d :pserver:jiangxin@10.0.0.152:/home/repos-user co -d steam_admin docbook/steam_admin# cvs -d :pserver:jiangxin@10.0.0.152:/home/repos-user co -d tip_sysinstall docbook/tip_sysinstall# cvs -d :pserver:jiangxin@10.0.0.152:/home/repos-user co -d lession_scm docbook/lession_scm# cvs -d :pserver:jiangxin@10.0.0.152:/home/repos-user co -d pm_fw_module_debug docbook/pm_fw_module_debug# cvs -d :pserver:jiangxin@10.0.0.152:/home/repos-user co -d steam_howto docbook/steam_howto
服务器端目录结构
# pwd/home/repos-user# mtree -cdin -k type # user: jiangxin# machine: openbsd# tree: /usr/home/repos-user# date: Tue Sep 10 21:34:26 2002/set type=dir. CVSROOT Emptydir .. .. docbook project .. docbook_howto .. images callouts .. .. lession_scm .. nightlybuild .. pgp images .. .. pm_fw_diary_2_4 .. pm_fw_module_debug .. pm_fw_plan_2_4 Attic .. .. program_rules .. rd_hwenv .. samples .. steam_admin .. steam_howto images .. .. steam_trans .. tip_sysconfig .. tip_sysinstall images .. .. .. jiangxin text apache .. config.network.linux .. db.mysql .. db.oracle Attic .. .. dns.bind .. email.qmail .. kernel.linux .. security.linux .. security.ssh .. utility.cvs .. utility.samba .. utility.xwindow .. .. web Attic .. doc .. html resources .. .. images gif .. png .. xpi .. xpm .. .. resource html .. ipaddr .. mailaddr .. pgpkey .. .. utility ltutil .. .. .. ....
客户端目录结构
# mtree -cdin -k type # user: jiangxin# machine: openbsd# tree: /usr/home/jiangxin/work/test# date: Tue Sep 10 21:24:33 2002/set type=dir. web CVS .. doc CVS .. .. docbook CVS .. project CVS .. .. docbook_howto CVS .. .. images CVS .. callouts CVS .. .. .. lession_scm CVS .. .. nightlybuild CVS .. .. pgp CVS .. images CVS .. .. .. pm_fw_diary_2_4 CVS .. .. pm_fw_module_debug CVS .. .. pm_fw_plan_2_4 CVS .. .. program_rules CVS .. .. rd_hwenv CVS .. .. steam_admin CVS .. .. steam_howto CVS .. images CVS .. .. .. steam_trans CVS .. .. tip_sysconfig CVS .. .. tip_sysinstall CVS .. images CVS .. .. .. .. html CVS .. resources CVS .. .. .. images CVS .. gif CVS .. .. png CVS .. .. xpi CVS .. .. xpm CVS .. .. .. resource CVS .. html CVS .. .. ipaddr CVS .. .. mailaddr CVS .. .. pgpkey CVS .. .. .. utility CVS .. ltutil CVS .. .. .. ....
6.2. Starteam 中的文件和目录的共享
Starteam 可以在同一 ServerConfiguration *享数据,既可以在不同视图,亦可在不同的工程*享。在图形界面下操作简洁。
但命令行不具有相应功能。