Parallel version System CVS Simple Tutorial CVS is an abbreviation for Concurrent Version System for version management. If you have participated in the projects that have collaborated with many people, everyone must have such a painful experience: Since many people have modified the same document, their own hard-modified procedures are completely deleted by others. Also, if your software / program has released three versions, at this time, the user needs you to modify the second version, maybe you will cry because only the latest version is kept. There is also some modifications to the program, but the modifications are very few, you only want to send a different version of the different versions to the distant colleagues, which can be exempted from the mailbox is not big enough, the network speed is too slow. . In order to solve problems like this, and, such as generating patch files, historical version modifications, a bunch of hackers (commendation) has developed CVS based on Mature SCCS and RCS in the original Unix system, developed CVS. (SCCS: Source Code Control System RCS: Revision Control System) The basic work idea of CVS is this: Create a repository on a server, and the source of many different items can be stored in the warehouse. The source program is managed by the warehouse administrator. In this way, it seems that only one person is like a file. Avoid conflicts. Each user first uses the warehouse to download the project file in the warehouse to the local. Any modification of the user is first conducted locally, then submitted by the CVS command and is unified by the CVS warehouse administrator. This will do tracking file changes, conflict control, and more.
Since CVS is a typical software software, it is also divided into two parts: the server side and the client. However, most CVS software combines them two.
In combination with documents and some online resources, I write a very simple "quick" textbook. hope its good for U.S. Here is my steps and practices:
Prerequisites:
ROOT permissions; CVS software, find related rpm, tgz, deb and other packages, or to http://www.cvshome.org/cvs/dev/code download the original program compilation installation, here I don't prepare to introduce it Please refer to the CVS own document installation. I use SLACKWARE TGZ package, the installed command is #installpkg cvs * .tgz other packages, please refer to the command of the corresponding package management tool. A certain system resource, there must be a certain amount of memory (32M can work very well), to have a certain disk space to see your size and how much. Set up a CVSRoot directory, because here involves the user's permission issues read and written on the file in cvsroot, so a relatively simple method is to create a group, then build an account belonging to the group, and later has read and write permissions Users must belong to this group. Suppose we built a group called CVS, the username is CVSROOT. The order and user's order is as follows
#groupadd cvs #adduser cvsroot
Home catalog in / home / cvsroot (adjusted according to your own system)
Use the cvsroot user to log in, modify the permissions of / home / cvsroot (cvsroot), and the authority to read and write with the same person:
$ Chmod 771. (or 770 should also) Note: This part of the work is done according to the documentation, there must be no trial, I will do this after doing the test, I have a little bit carefully. If you have this experience, please give me, thank you. Establish a CVS warehouse (still cvsroot users), with the following command:
$ cvs -d / home / cvsroot init
Log in as root, modify / Etc/inetd.conf (using xinetd "does not have this file) and / etc / services, if you use inetd, add: Cvsserver Stream TCP NoWait Root / usr / bin / cvs cvs -f - allow-root = / home / cvsroot pserver
Note: The above line is a single line, / usr / bin / cvs should be your CVS version of the command path, please adjust according to your system. / Home / CVSROOT is the path to the cvsroot you created, and also adjust it according to the contents of the part of the directory above.
If you are using the XINETD system, you need to create a file CVSPServer in the /etc/xinetd.d/ directory (this name can be defined by yourself), the content is as follows:
# Default: on # description: The cvs server sessions;
Service cvsserver {socket_type = streamwait = number = rootserver = / usr / bin / cvsserver_args = -f - allow-root = / cvsroot pserverlog_on_failure = useridonly_from = 192.168.0.0/24}
The only_from is used to restrict access, and can be not or modified according to the actual situation. Modify this file permission:
# chmod 644 CVSPSERVER
Join / etc / services:
Cvsserver 2401 / TCP
Note: CVSServer is any name, but cannot be reinable with the existing service, but also to modify the first item of /etc/inetd.conf above. Here I use CVS password authentication method, CVS has other authentication methods, I have not tested, if you have experience, please add, thank you.
Adding a user who can use CVS services to CVS group: Modify / etc / group as root, add the username of CVS to the CVS group, such as what I want to let the user Laser and GumpW can use CVS services, then modified / etc / group should have the following rows: CVS: X: 105: Laser, Gumpwu
GID on your system may not be 105, there is no relationship. Mainly to separate the Laser and Gumpwu to the last colon with a comma. Of course, like the distribution of the RedHat has tools like LinuxConf, do this will be simpler.
Heavy inetd makes the modification take effect:
#killall -hup inetd If you are using Xinetd's system: # /etc/rc.d/init.d/xined restart
This way the server is set up. We will then engage in the client.
Set the client
If it is Linux (or other * NIX), the client and server software are the same, if it is Win, Mac and other platforms, please
http://www.loria.fr/cgi-bin/molli/wilma.cgi/rel
Looking for the corresponding client software, here I will talk about how to do it in Linux (* niX):
Set environment variables cvsroot:
$ export cvsroot =: pserver: Laser @ THE_SERVER_NAME: / home / cvsRoot Note: The PServer here is an access method, I set it up for password authentication, so this is a PServer, if your CVS server sets the access mode, Then you need a corresponding modification. Laser is a username that can use the CVS server. Here you can modify it according to your settings. I set up the password files of the system user in this version, that is, the Laser must be a legitimate user on the CVS server, which is of course secure. Question, CVS can be set to have its own users, I will add this content in the later version, or you can also provide some additions, or directly read CVS documents. The_server_name is the name or IP address of the CVS server. Fill in your situation, / home / cvsroot is your CVSRoot directory of your CVS server, modify or ask the administrator according to your CVS server settings. You can put this line in your shell's profile (.bash_profile, .profile, etc.) This will not have to knock a long string command each time.
Log in to the CVS server:
$ CVS login, this time CVS will ask you a password, please knock in the password you on the CVS server, here is the password of the system user on the CVS server: Passwd: xxxxxxxx
After successfully logging in, you will build a .cvspass file in your home directory, you don't have to enter your password.
Ok, the client setting is complete, simple. Manage CVS servers
The server can be used, and now everyone is most concerned how to manage the server, for example, I want some people to read and / or write the permissions of the CVS warehouse, but don't want to give it system permissions?
It is not difficult, there is a cvsroot directory in the cvs administrator user (in the cvsroot user), this directory has three profiles, passwd, readers, Writers, we can configure CVS by setting these three files. The server, the following is the role of these files, respectively:
Passwd: CVS user user list file, its format is very like shadow file:
{CVS User Name}: [Encrypted Password]: [Equivalent System User Name]
If you want a user just a CVS user, not a system user, then you have to set this file, then this file may not exist after you have installed, you need to create a CVS administrator user, of course, according to the format, second The field is the user's encryption password, which is encrypted with Crypt (3). You can write a program to do encryption, you can also use the lazy way I introduced: first create a system user, name, and CVS users. The password is ready to give it a CVS user password. After creation, copy the second field from / etc / shadow to the second field, and then remove this user. This method is more convenient to deal with fewer users, and people are not suitable, and there are also safety hazards of conflict conditions. However, the equivalent is. Write a small program is not difficult, you can search for the LinuxForum programming version, have a friend has written a post above. The third field is an equivalent system username. In fact, it is to assign an equivalent system user with a CVS user. Look at the following example you understand its function.
Readers: A user list file with CVS read rights. It is a one-dimensional list. Users in this file have only read permissions for CVS.
Writers: a list of users with CVS write permissions. Like readers, it is a one-dimensional list. Users in this file have write access to CVS.
The above three files may not exist when the default installation, you need to create it yourself, ok, now let us use an example to teach. Suppose we have the following users to use CVS:
Laser, gumpwu, henry, betty, anonymous.
Where Laser and Gumpwu are system users, and Henry, Betty, Anonymous we don't want to give system user privileges, and Betty and Anonymous are read-only users, and Anonymous is even more than. So well, let's do some ready to work, first create a CVSPUB user, this user's responsibility is to read and write CVS warehouses on behalf of all non-system users.
#adduser ...
Then edit the / etc / group, let CVSPUB users in the CVS group, while adding other users with system user privileges to the CVS group. (See above)
Then edit the cvsroot / passwd file in the CVS Administrator's Catalog, add the following line:
Laser: $ xxefajfka; faffa33: CVSPUB GUMPU: $ AJFAAL; 323R0OFeeanv: CVSPUB HENRY: $ FAJKDPAIEJE: CVSPUB BETTY: FJKAL; FFjieInfn /: CVSPUB Anonymous :: CVSPUB
Note: The second field above (separator is :) is a secret text password, you want to use the program or use my dirt.
Edit the readers file, add the following line:
Anonymous Betty
Edit the Writer file, add the following line:
Laser gumpwu henry
This is OK, you will use several users to log in to test, and you will find everything OK. The principles and instructions in this are not much to say, in fact, very simple, and the concept of system management users. Now that the server and client are set up, so how to use it, I will write a simplest (estimated is also the most common) command:
First, establish a new CVS project, usually there are some project files, so we can generate a new CVS project with the following steps:
Enter your existing project directory, such as CVSTest: $ cd cvstest running command: $ cvs import -m "this is a cvstest project" cvstest v_0_0_1 start Description: IMPORT is one of the commands of CVS, indicating input to CVS warehouse project files. The string behind the -m parameter is a description text, and write some meaningful things. If you do not add -M parameters, then CVS will automatically run an editor (generally VI, but can change to you by modifying environment variable editor) I like to use the editor.) Let you enter information, cvstest is the project name (actually a warehouse name, which is stored in the warehouse named after this name.) V_0_0_1 is the total mark of this branch. Nothing is used (or is not common.) Start is a tag of the input level of the import logo file, no use. In this way, we have built a CVS warehouse, then we can delete this test item file. Test how to get documents from the warehouse. Here I assume that all clients above have been done. Run the following command:
$ CVS Checkout Cvstest Retrieves the source file for the CVSTEST project from the warehouse. If you have already done Checkout, then don't need to re-checkout, just enter the directory of the CVSTest project, update it, you will do it:
$ CD CVSTEST $ CVS Update. Or you don't want to update directly, just want to see if there is any updated thing, then: $ cvs status will print a long string status report (you may need to use a command paging like LES, or to one Slowly see in the output file.), There is a status report on each file in the project, similar to this: ========================== ================================================================00 To-date
Working Revision: 1.1.1.1 'Some Date' repository revision: 1.2 /Home/cvsroot/cvstest/foo.c ,v sticky tag: (none) Sticky Date: (None) Sticky Options: (NONE)
The most important thing here is the STATUS bar. There may be four states here: up-to-date: Indicates that the file you want is up to date. Locally Modified: Indicates that you have modified the file, but have not submitted, your version is new than the warehouse. Needing Patch: Indicates that some buddies have modified the file and have been submitted! Your version is more than the old in the warehouse. Needs Merge: Indicates that you have modified the file, but there is a non-known phase and modify this file, and it is also submitted to the warehouse!
If you just want to keep the software synchronization (like me), then the above thing is enough. However, if you work together to develop a project, it is not so simple. When you participate in the project, when maintaining the file, you need more commands. For example, you are a developer of a NASDAQ project:
1. You have modified a file, such as CEO.c, plus a line: Printf ("Where can I find vc to cheat!"); After you finish, you have to submit a modification to the warehouse, use Command: $ cvs commit -m "add a company" CEO.c or is: $ cvs commit -m "Worry About Money" Let CVS help you check which file needs to be submitted.
2, when I start working, maybe I first: $ cvs status, then I will see:
============================================================================================================================================================================================================= ================ File: CEO.C Status: Needing Patch
Working Revision: 1.1.1.1 'Some Date' repository revision: 1.2 /Home/cvsroot/nastaq/ceo.c ,v sticky tag: (None) Sticky Date: (None) Sticky Options: (None)
So I know that someone has changed CEO.c, so I just: $ cEDATE CEO.C or simply: $ CVS Update Update CEO.c This file is the latest version, and then work. Then submit it. If you have modified coo.c this day, Puts ("How About ANOTHER KIND OF Bragging?"); And submitted, but at this time I have already $ crs status, that is, I don't know your changes. And I added a line of Printf ("You Must Shameless and Seems Knowingness to Act As a Coo"); and Submitted: $ CVS Commit Co.C, CVS will tell me CVS Commit: Examing. CVS Server: Up- To-date check failed for 'coo.c' CVS [Server Aborted]: CORRECT ABOVE ERROR FIRST!
So I knew that there was a shit and made a submit in the mouth of the file, so I cvs Update At this time, CVS will report: rcs file: /Home/cvsroot/nasdaq/coo.c ,v retrieving revision 1.1.1.1 Retrieving Revision 1.2 Merging Difference Between 1.1.1.1 and 1.2 Into coo.c rcsmerge: warning: conflicts during merge cvs Update: conflicts found in coo.c c coo.c tells you that there is a version conflict, so I edited coo.c, this At general files look like this: ... Printf ("You Must Shameless and Seems Knowingness to Act As a Coo"); <<<<<< Foo.c ======= ... Puts ("How About ANOTHER KIND OF Bragging?"); >>>>>>> 1.2 ...
So I changed the above: Printf ("You Must Shameless and Seems Knowingness To Act As a Coo"); PUTS ("How About Another Kind of Bragging?"); Then $ cvs commit -m "merge" coo.c When you go back, you have a new patch to play when you update it. . . This is so recovered until all modifications are completed. However, there are some ways to pay attention to the delete program. If you delete the program PUTS ("to be honest") that you may not use; and I don't want to delete (because I use it), and I don't know directly: $ CVS Update, then my line program is finished, so we should pay attention to all developers' coordination, don't delete things, big deal with #IF 0 #ndif macro confedes. I really want to delete things, it is best to mark a version: $ cvs tag v_0_0_1
Then you can post and delete this version of this version in your own working directory (Note: Not deleting the warehouse.): $ Cvs Release -d Nasdaq
Then you regenerate a new branch:
$ CVS RTAG -B -R v_0_0_1 v_0_0_1_1 NASDAQ
Then establish a branch of v_0_0_1_1
$ cvs checkout -r v_0_0_1_1 nasdaq
Edit and modify this branch file, this is better.
However, it is important to note that the establishment of new tags and new branches is the best responsible by the management of the project. Otherwise everyone is a branch, then the warehouse is too mess. Therefore, the direct communication between the comparison developers cannot be ignored. In general, the standard mode on the Internet is an administrator (may not write a program), there is a list of posts, and everyone exchanges views on the post list and makes various resolutions. When the resolution is formed, the administrator makes a new version of the tag. Take this cycle.
There are still some commands, such as adding a file GARBAGE_CHINA_CONCEPT_STOCKS_LIST:
$ cvs add garbage_china_concept_stocks_list
Then you need to:
$ cvs commit grumbage_china_concert_stocks_list
It looks a bit like a business in a database? It is indeed this. CVS maintains a local reference file (in CVS / ENTRIES) so that all changes can be placed on the server at once, which is safer. Similarly, if you want to delete files Bankrupted_web_site:
$ RM BANKRUPTED_WEB_SITE $ CVS Remove Bankrupted_web_site $ cvs commit banrupted_web_site
3, some tips: $ header $ tag: Place this tag anywhere in the file will be replaced by CVS to the last modified CVS username, the current version number, final modification time, the file's CVS warehouse path, see Get up like this:
// $ header: /Home/cvsroot/simhost/simhost.cpp ,v 1.2 2001/04/20 08:26:10 JQLIU EXP $
Generally we put it at the beginning, so that the programmer modifies the file very convenient, many times you just know if the file is the latest.
$ ID $ tag: Place this tag anywhere in the file will be replaced by CVS to the last modified CVS username, the file current version number, final modification time, the CVS warehouse path of the file, looks like this:
$ ID: Simhost.cpp, V 1.3 2001/04/24 02:27:36 Simhost Exp $
