使用的CVSNT版本是:
1e37ea2e4ebf880c1ec516c263df7527 *cvsnt-2.5.01.1976.msi
折腾了我一天, 总算把CVS中watch 事件发生时自动发送邮件的功能给搞定了.
这其中碰到不少新问题:
1. CVS的文档中说, Repository目录下的CVSROOT也正如普通目录一样, 你可以对其中的文件checkout, 修改, 提交, 这种语法是很容易误导人(至少误导了我), 因为并非所有该目录下的文件都可以以这种方式来做修改.
举例来说:
passwd
文件放着CVS的用户名和密码, 一行一个, 两者用:隔开.
这个文件就不能
admin
也不能以这种方式进行操作, 在 看到了一篇文章中说的很清楚:
But with editing a file called admin you can define the system user(s)
that should be CVS admin(s). This file has to be edited directly on the
server and should
not be handled via CVS.
2. cvs的内部实现维护了CVSROOT 目录下那些特殊的文件名, 当你提交这些特殊文件时, 一个特别的信息显示出来:
cvs server: Rebuilding administrative file database
这里所谓的重建管理文件数据库, 其实是CVS根据你新提交的文件, 产生出该文件的一个最新版本, 比如对于config 文件, 用户看到的是config, 但CVS管理下的目录中记录各版本修订变化的文件名叫 config,v 这一命名规范对所有的CVS管理下的文件都是一样, 但对于CVSROOT目录下的这些特殊文件, 有一点是不同的, 那就是CVS 服务程序需要访问的不是 config,v 这样的文件. 而是config这样的有着简单和良好定义了其格式的文件. 所以重建管理文件数据库就是产生该文件的最新版本.
3. 对于在WINDOWS 上运行的cvsnt来说, 有两种方式管理CVS的帐号:
3.1 是混合方式管理, 既可使用windows 本身的用户名, 密码登录, 也可使用CVS自己的用户名管理系统, 这种方式下对于CVS自己的用户名管理系统, 每个CVS用户必需"链接"到一个真正的WINDOWS操作系统帐户.
CVSROOT/config 中的
SystemAuth=yes
这一行或简单地把这一行注释掉(默认的工作方式)决定了CVS以该方式工作.
具体"链接"是通过
cvs passwd -r os_user -a new_cvs_user
中的-r参数指定的os_user
在password文件中表现为:
cvs_user:password:os_user
这是三段, 其中:os_user对passwd文件格式来说是可选的部分.
3.2 仅使用CVS自己的用户管理系统.
此时
SystemAuth=no
用户帐号登录, 密码管理等都与WINDOWS的帐号系统无关.
但此时注意, CVSNT的控制面版中, 有一项是Run as, 这个一定不能选择 (client user), 而要选择系统上一个真正的用户帐号, 否则, 可以想象, 因为登录的客户端用户不是一个合法的WINDOWS用户, 而服务却要强行以这样的用户身份运行, cvs login会失败, 而且从失败信息中你绝对找不着北.
改变这个之后不需要重启CVSNT服务, 点击下面的"应用"按钮即可生效.
4. 新版本的cvsnt 使用了ACL(Access control list), 原来用来在服务器端 记录哪些文件被 watch, 哪些用户请求watch这些信息被放在了新的XML格式的 fileattr.xml 文件中, 仍然位于服务器上CVS这个特殊目录下.
fileattr的样例文件:
<?xml version="1.0" encoding="UTF-8"?>
<fileattr>
<directory>
<acl user="zrf2">
<all />
</acl>
<owner>zrf</owner>
</directory>
<file name="a.txt">
<editor name="zrf">
<hostname>vzhao</hostname>
<pathname>C:\asdf</pathname>
<time>Wed Apr 23 09:20:04 2008 GMT</time>
</editor>
<watched />
<watcher name="zrf">
<commit />
<edit />
<tcommit />
<tedit />
<tunedit />
<unedit />
</watcher>
</file>
</fileattr>
|
XML格式就是能让人一目了然.
其中的 tedit, tcommit 代表 temporary, 具体什么叫temporary我还没搞明白.
CVS的watch/edit/unedit/commit 机制能够做到通知开发者的原理是这样的:
(A) 定义CVSROOT下的notify 文件, 每行一条规则:
Regex command with %s %b etc as parameters
正则表达式匹配的是当前被关注的那个目标文件或目录对于当前 Root的相对路径, 这是文档中的说法, 我还没有验证, 它的正则表达式我猜测是与PCRE兼容的, 因为看到它用了PCRE的库.
主要的工作都在Regex后面的命令中完成, 这个命令往往是自己写的一个脚本, 完成向其它开发者通知的功能
用空格分隔两个部分.
每次cvs服务器得知某个用户要edit/unedit/commit 一个文件, 且通过 fileattr.xml 检查到该文件处于监控之下, 就会执行notify文件中的规则.
(B) 具体哪个文件或目录受到监控由 cvs watch on [dir | file ] 控制. 这个命令会产生或修改 fileattr.xml 文件
(C) 具体被监控的文件有哪些用户对edit/unedit/commit中的哪些事件请求通知则通过
cvs watch add [dir | file...]
修改fileattr.xml 实现.
总之, 哪些目录, 哪个文件受到监控, 哪些用户希望监控它, 以及这些用户各自对哪些事件发生时要求监控都由 fileattr.xml的存在与否以及其中的内容决定.
与cvs watch add 相反的命令是 cvs watch remove
(D) 用户1 对一个目录/文件 执行cvs edit时, edit会与CVS服务器通讯, CVS服务器检查fileattr.xml的存在性及内容, 然后执行由notify中定义的规则.
(E) notify中定义的命令行程序, 其标准输出和标准错误输出都会通过网络(假设以Client/Server结构使用CVS) 送到用户端.
5. 新建立的用户默认(可能)没有checkout 这样的基本权限, 同样是被 ACL所控制.
此时需要用 cvs chacl -u new_user -a all proj_dir
来赋予该用户一些权限.
6. 可以通过 checkoutlist 来让CVS管理CVSROOT下额外的一些文件.
checkoutlist 的名字很不好, 它的真正意思是:
定义一个这样的文件列表, 这些文件位于CVSROOT目录下, 但不属于CVS本身内置管理的文件, 要求这些额外的文件被CVSROOT 管理.
这里管理一词可能暗示着这样的操作:
每次check in(commit)该文件时, 会执行一个rebuilding administration file database的动作, 也就是产生该文件的一个最新版本, 文件名要保持用户视角的原始文件名. 而不是加了,v的CVS管理文件.
7. CVSNT跟普通的CVS一样, 一经登录, 后续的操作就不需要再输入密码了, 但密码还是要对每个CVS命令都传送给CVS服务器的, 密码存储在哪里?
标准的CVS文档总是说在 $HOME/.cvspass 文件中, 对于cvsnt, 不是这样, 它存储在注册表中, 具体说是:
经过我验证的确如此:
而且是对不同的工作目录, 不同的 CVSROOT登录都各自保存.
8. cvs lock服务可能会产生CVSROOT目录下一些文件带~后辍的版本:
config~ 这样的文件. 可能是为了防止在一个会话期中被非法修改.
