I do three days of work results, and everyone share established and configured operations are done on Redhat Linux8.0. The CVS executable program of the system belt is under / usr / bin, version information is: Concurrent Versions System (CVS) 1.11.2 (Client / Server). This CVS executor with the system can be used in both the client, or to establish a CVS source code library server. Establishing a source code base has the following steps: (1) Initializing the CVS server environment. #CVS -D / usr / local / source init, enter / usr / local / source, you can see a directory cvsroot, below is the initialized CVS server profile. Temporary. (2) Put the CVS service into the xinetd system service. First Generate Task Profile CVSPServer in the /etc/xinetd.d directory, file names can be used casually. The content is approximately as follows:
Service CVSPServer
{
Flags = Reuse
Socket_type = stream
Wait = NO
User = root
Protocol = TCP
Server = / usr / bin / cvs
Server_args = -f - allow-root = / usr / local / source PServer
Disable = no
}
Where Server_args a parameter specifies the source code library path, one specified server uses a password authentication method. Second, to confirm that in the / etc / services file, there is a CVSPSERVER keyword, and allocated ports, such as: CVSPSERVER 2401 / TCP. Third, restart the Xinetd service, the CVS service can be used. (3) Test. It is assumed that the CVS server has a user CVS on the system on 192.168.0.205. Log in to another Linxu machine, perform the following commands to complete the test: $ export cvsroot =: pserver: cvs@192.168.0.205: 2401 / usr / local / source $ cvs login Enter the password, no error message indicates that the login is successful. If you want to build multiple source code libraries on a Linux system, you provide CVS services. Repeat the above steps. Pay attention to using a different path when you first step first. The second step is placed in the XINETD system service. To generate a new task profile, such as CVSPServer1, the service name, such as the service name, such as Service CVSPServer1, Server_args. Also in the / etc / services file, add new service port numbers, such as CVSPServer1 2402 / TCP. Restart the xinetd service. The third step is tested, you can set it: $ export cvsroot =: pserver: cvs@192.168.0.205: 2402 / usr / local / source1 CVS as a parallel version control system, multi-user read and write is required . But sometimes I hope some users can only check out and cannot submit new code. Sometimes some users on CVS cannot check out some code, such as sharing a CVS with another development group, and hope that the member of the other group cannot check out the code. The CVS server has a set of user authentication mechanisms. I didn't use it when I used, but used the system as a CVS server user, using the Linux group, and user permissions achieve such functions. For example, an actual two development groups A, B are simulated on the LinxU system, and some user A-USER1, A-USER2, B-USER1, B-USER2 are simulated. Module A-SOURCE, I hope A group members can read and write, and B group members do not have any permissions. You can use the following series: #Chown -r A-user1 a-source #chgrp -r 770 a-source If you want the module A-Source, only A-USER1 can be written, other users of the same group You can read, the B group member does not have any permissions, and the chmod command is changed to -r 750. Must be explained, the default of the default of the user Checkout code will generate a lock file under the current module. If this user does not write permission to the current module, it is impossible. To match the above permissions, you must change the CVS server configuration. Change to generate a lock file in the current module directory, and the lock file is set to a directory of all users have read and write permissions. Modify the configuration file cvsroot / config: # put cvs Lock Files in this directory. # Lockdir = / var / lock / cvs can set the lockdir. Posted on August 16, 2004 11:21 am
