CVS在windows下安装配置使用.docx
《CVS在windows下安装配置使用.docx》由会员分享，可在线阅读，更多相关《CVS在windows下安装配置使用.docx（20页珍藏版）》请在冰豆网上搜索。
CVS在windows下安装配置使用
1Cvs简介
CVS是ConcurrentVersionsSystem（并发版本系统）的简称。
它是一个开放源代码的项目，是当前最流行的版本控制系统，目前绝大部分OpenSource项目都使用它来做版本管理。
如果你还习惯用微软的VSS来进行Java项目的版本管理，那么用上Eclipse后，建议还是转为使用CVS。
CVS采用客户机/服务器体系，代码、文档的各种版本都存储在服务器端，开发者首先从服务器上获得一份复制到本机，然后在此基础上进行开发。
开发者可随时将新代码提交给服务器，当然也可以通过更新操作获得最新的代码，保持与其他开发者的一致。
Eclipse本身内置了CVS客户端，只要再建立一个CVS服务器就可以使用这一功能强大的版本控制系统。
CVS的功能虽强大，但一般项目通常只用到其20%的功能，所以只要了解最常用的操作就可以了。
2安装cvs
2．1安装cvsnt
直接安装，无特殊操作，一直“下一步”，安装到默认目录c:
\ProgramFiles\cvsnt中。
3配置cvs
3．1配置一个Repositoy
使用“开始-所有程序-cvsnt-Servicecontrolpanel”来建立一个Repositoy。
在repositoryconfiguration选项卡中点击add添加
在location中填写存放位置，name中最好填写location中的内容，否则可能出现异常
点击ok后2个弹出窗口中都点击yes
在compatibilityoptions选项卡中将cvsntclients中的前三项都点上勾，点击确定
这时我们的初步配置便完成了，c盘下会出现名为cvsfile的文件夹
3．2进行用户建立和配置
Repository配置完成后cvs会将当前windows登陆用户作为cvs的admin用户，但使用操作系统用户会较麻烦和缺乏安全性，所以我们将禁用操作系统用户。
在服务器端为Windows添加一个专门用于CVS操作的Windows帐户。
所有的CVS帐户都要映射到这个Windows帐户上进行实际的操作。
虽然很多资料并没有提到需要建立Windows帐户，但我在实验中发现没有这种帐户，CVS在后边执行任何操作时都会报告没有此帐户的错误。
假如这个新的帐户叫做cvsuser，密码为cvs。
现在我们给cvsuser用户cvsfile文件夹的操作权限。
首先在工具——文件夹选项——查看中的“使用简单文件共享”的勾点掉。
然后在cvsfile属性——共享中设置共享属性。
点击共享此文件夹，点击权限。
删除everyone，添加cvsuser。
并给它完全控制权限。
电击确定完成操作。
现在我们开始建立自己的cvs用户。
首先运行cmd
设置cvsroot环境变量（请注意区分cvsroot目录和cvsroot环境变量），不加盘符。
D:
\>setcvsroot=:
pserver:
Server@TNET-server:
/cvsfile
登陆。
输入windows系统登陆密码。
Chackout出cvsroot。
运行：
cvscoCVSROOT
此时c盘下会有一个叫“CVSROOT”的目录。
为CVS添加自己的帐户。
通过使用命令cvspasswd我们可以添加任意多个CVS帐户（当然，只是针对当前的Repository）。
所有的帐户信息会被保存在CVSROOT目录的passwd文件当中。
然而这个文件是不能CheckOut出来的，只能在服务器那里看到它，并且其保存的密码信息是被加过密的。
我们为操作系统的cvsuser用户添加1个叫cvsadmin的cvs用户，密码为admin。
设定cvsadmin为CVS管理员。
在客户端的CVSROOT目录下新添一个名为admin的文件。
在里面将每一个想要升为管理员的CVS帐户的帐户名写到文件中，每行一个帐户名。
当然admin文件只有放到服务器，cvsadmin的升迁才能生效。
但是，仅仅是这么将admin文件提交上去是不能起作用的。
在提交它之前，必须将admin的信息添加到checkoutlist文件中。
checkoutlist的格式在文件中有介绍，是“空格文件名空格出错信息回车符”。
我们在里面添加一条记录：
adminadminerror。
特别注意admin前面一定要留一个空格。
当新的CVS管理员和帐户信息都准备好后，就要将帐户校验模式从“操作系统集成校验模式”修改为“仅使用CVS帐户校验”模式。
这么做可以避免为了在CVS中使用多用户时需要操作Windows帐户的麻烦。
这个设置的地方在CVSROOT目录中的config文件。
打开客户端的config文件，将里面的#SystemAuth=yes改为SystemAuth=no（注意将#删除后，SystemAuth前不能有空格）。
修改后保存config文件。
提交CVSROOT里的所有更新到服务器，我们的设置就生效了。
运行：
cdCVSROOT
cvsadd–m“”admin
cvscommit–m“”
到这里我们对cvs的用户建立和配置就完成了，我们随时可以为cvs添加用户。
3．3cvs用户权限分配
修改读写权限。
CVS有两种读写权限的设置方法，一是粗粒度的，一是细粒度的。
只有CVS管理员才能进行访问权限的修改。
粗粒度的方法是在CVSROOT中添加readers或者writers文件来实现。
在readers里添加的任何一个帐户对当前库只拥有读取权限，添加格式是每行一个帐户名。
例如，我们在客户端的CVSROOT目录里添加readers文件，将之前的一个新建帐户anonymous放到里面，然后commit这个readers文件到服务器。
anonymous就不能进行commit了。
实际的测试结果是在使用anonymous登陆之后执行commit指令，系统会报告正常执行完毕。
但实际上，没有任何东西被commit，暴露了CVS在人机界面上的不完善。
writers文件的操作readers完全一样。
如果一个帐户名被同时写到两个文件里，此帐户只有只读权限。
细粒度的方法是使用chacl命令。
例如c:
\cvsfile里有3个工程，project1、project2、project3。
使用命令：
cvschacl-anone-uuser1project1,project2,project3
cvschacl-aall-uuser1project1
cvschacl-aread,write-uuser1project2
cvschacl-aread-uuser1project3
可以让user1拥有对project1目录的完全控制权，对project2目录的读写权，和对project3目录的只读权。
第一条命令首先删除user1的所有权限，在随后的3条命令里分别设置了3个不同目录权限。
4测试
4．1配置Eclipse的客户端来连接上CVS服务器。
我们在eclipse中建立一个叫TestCvs的工程，在com包下建立一个带有main函数的类，起名Test，在main函数中让它输出“HelloCvs!
”
打开Eclipse中的“CVS资源库研究”透视图，然后在左部的“CVS资源库”视图单击右键，在右键菜单中选择“新建→资源库位置”选项。
在弹出的窗口输入CVS的相关信息，填完后单击“完成”按钮。
4．2将项目提交到CVS服务器上
转到Eclipse的“资源”透视图。
右键单击项目名myproject，然后选择“小组→共享项目”选项，如图5.6所示。
在弹出的“共享项目”窗口中，接受默认设置，直接单击“下一步”按钮。
选择我们刚配置好的连接，单击“下一步”按钮。
再点下一步直到完成。
我们的项目就发布到cvs服务器上里
4．3CVS服务器上的项目导入到Eclipse中
在主菜单选择“文件→导入”选项，选择“projectsfromcvs”。
选择连接
为从cvs导入的工程起名（建议用原名）
完成。
4．4用户权限测试
我们新建2个用户test1和test2，密码分别是test1和test2。
只给test1读的权限，而给test2读和写的权限。
我们用test1来进行连接，在Test类的main函数中加入一句“System.out.println（“Test1”）;”。
保存后提交cvs服务器。
会报错。
而我们用test1来与服务器进行比对。
不报错。
可以看出test1有读权限但无写权限。
我们用test2来连接cvs服务器。
修改Test类后再进行commit操作。
提交会成功，Test类的版本号会变为1.2。
证明test2有写权限。
5cvs其他使用方法（转）
5．1从CVS更新文件到本机
要将CVS服务器上的最新代码更新到本地，有以下两种方法：
（1）右键单击Test类，在弹出的菜单中选择“替换为→HEAD的最新内容”选项。
（2）右键单击Test类，在弹出的菜单中选择“小组→与资源库同步”选项，在弹出的同步界面，单击“将当前更改从右边复制到左边”按钮，然后保存。
5．2解决文件提交的冲突
如果2人同时在同一个版本的文件中进行了修改并提交的话，先提交成功的人后正常进行操作，而后提交成功的人需要先与服务器同步之后取得新版本之后再提交。
（所以每次提交前都与服务器同步一次是个好习惯）
5．3如何忽略掉不想提交的文件
假设当提交一个项目bin目录包含的是编译后的class文件，没有必要将它提交到CVS上。
我们可以右键单击它，然后在弹出的快捷菜单中选择“添加至.cvsignore”，这样bin目录就被忽略掉，不会提交到CVS上。
5．4版本打包
在开发告一段落时，就要打包一个版本，打包版本的操作步骤如下：
（1）右键单击“项目名”，在弹出的快捷菜单中选择“小组→标记为版本”选项。
此时如果有修改没有提交到CVS上，则会弹出下如图5.4.1所示的一个提示框，如果单击“确定”按钮，则未提交的修改就不会包含在本次打包的这一版本中。
（2）如图5.4.2所示，在窗口中为此版本起一个名称为V001。
由于此名称可能已存在于CVS中，所以下面还有一个复选框，如果选上该复选框，在打包时就会替换掉同名的老版本；如果没有选上，则在有同名版本时，就会弹出错误提示框。
图5.4.1确认未提交的更改图5.4.2给版本起名
如果版本已经打包，但后来发现有一个文件有点问题，于是想把这一个修改的文件更新到上一个版本中，但另外一些修改的文件则不想更新到上一个版本。
这时如果再通过右键单击项目名来打包，则项目所有修改的文件都会被更新到上一个版本中。
正确的操作步骤如下：
（1）将修改的文件提交到CVS上。
（2）右键单击该修改文件的“文件名”，在弹出的快捷菜单中选择“小组→标记为版本”选项。
（3）在图5.4.2中，还是起名V001，并且要选择复选项，然后单击“确定”按钮。
此操作和打包项目版本惟一不同之处是：
前者右键单击“项目名”，后者右键单击修改文件的“文件名”。
5．5将项目替换成CVS上的其他版本
接着5.4节内容，当打包成版本之后，如果要将此版本还原回项目中，则操作步骤如下：
右键单击“项目名”，然后在弹出的快捷菜单中选择“替换为→另一个版本或分支”选项，得到如图5.5.1所示窗口，选择版本V001，单击“确定”按钮。
注意：
此操作会将本地所有的修改都覆盖掉，所以在操作之前先把本地修改提交到CVS上保存。
图5.5.1CVS的分支版本列表
5．6修改旧版本的BUG
如果已经发布了软件的1.0版，而现在正在开发2.0版，但用户在使用1.0版的时候发现了一些BUG，这时就需要修改1.0版的这些BUG，具体修改操作步骤如下：
（1）将CVS导出成另外一个项目。
其他步骤都一样，仅在最后一步时，输入另外一个项目名myproject2。
这样分成两个项目后，修改旧版本和开发新版本就可以同时进行而不互相干扰。
（2）用5.5节的替换版本操作将myproject2项目替换成V001版本（假设V001就是出问题的1.0版）。
如图5.6.1所示，在图中可以看到myproject2的后面跟着一个V001版本标志。
图5.6.1从CVS导入的myproject2
（3）这时还不能在myproject2上修改，即使修改了也提交不上CVS。
因为还差一步，即需要为V001版创建一个分支，操作步骤如下：
右键单击myproject2的项目名，然后选择“小组→分支”选项，在弹出如图5.6.2所示的窗口中输入分支名V001_patch，并单击“确定”按钮。
说明：
很容易把“分支”和“版本”看成类似的概念，但实际上“分支”是和HEAD的概念比较接近，“提交”操作只能将文件提交到HEAD或分支上。
（4）如图5.6.3所示，myproject2的项目名后就有了一个分支名V001_patch，表示该项目已经在这个分支下工作了。
图5.6.2设定分支名图5.6.3myproject2在V001_patch分支下
（5）现在可以在myproject2项目中将BUG修改好，并提交到CVS上了。
不过要说明的是，修改不是提交到HEAD上，而是提交到分支V001_patch上，所以也就不会影响到软件2.0版的开发。
提交之后，文件尾部的版本号也起了变化，如图5.6.4所示。
图5.6.4在分支下的程序版本号
（6）当修改完BUG后，就可以给软件再打一个版本V100_1，并将修正了BUG后的版本发布给用户。
6实践建议（转）
（1）把项目做成模块目录（Java包），各人负责自己的模块和目录，这样就不容易造成重复修改。
（2）做到每日提交，即每天下班之前都要将各自完成的代码提交到CVS上，并且提交的代码要求是完整可运行的代码，关键是要保证其他人更新你的代码之后不会引起错误。
（3）对于共用型的文件，要做到即时修改，即时提交。
（4）任何人在修改文件之前，先同步查看并更新CVS的最新版到本机。
（5）项目团队的Eclipse等开发环境（安装目录、软件版本等）要保持一致。
这样就可以将整个项目共享到CVS，团队成员也可以从CVS上更新整个项目，而不必担心因为一些项目配置文件不同导致更新项目后出错。
另外，当新团队成员加入时，只要导入CVS上的整个项目，无须再配置项目，就可以即刻开发运行。
升级会员 