Use CVS for project development management

Article Title: Use CVS for project development management. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.
When many people develop a large project together, source code maintenance and version maintenance are a headache. because many people develop, each developer has a copy of this project, therefore, it is very difficult to manually maintain the modifications of multiple users in the same file.
In addition, the project version you need may not be the latest version. It is almost impossible to keep a backup for each version for this purpose. The Linux platform provides a functional software: CVS. As we all know, the development of Linux has benefited from the development of the Internet. Most of the software is jointly developed by many developers on the Internet. Most of the maintenance of these software uses CVS, for example, Deban Linux development, KDE development, and sourceforg development projects. Correct and skillful use of CVS is a basic quality for Linux programmers.
　　
　　
Instead of maintaining the source code, CVS can be used to manage all text files. Of course, it can also manage binary files, but it only requires special Command Options.
　　
CVS stores files in a place named repository. The files saved in the repository are not copies of each version, instead, you can trace back to the master information of some code of the initial version from any version, which saves a lot of storage space.
A repository can be created not only on a local machine, but also on a network. In addition, CVS supports version Branch (tag), which can be derived from any version for development. If necessary, the branch can also be merged into the main development branch.
　　
CVS needs a software named "revise control system". To be exact, CVS mainly manages the changes to directories in development projects, while RCS focuses on the changes to a managed file. To use network CVS, you also need rsh or your built-in cvs-server. rsh is the communication platform of the CVS client on the server. To transmit secure information, you can use ssh, this can be specified using the CVS_RSH environment variable:
Export CVS_RSH = rsh use rsh
Export CVS_RSH = ssh
　　
Use of RCS
Before using CVS, we will first introduce how to use RCS.
As mentioned above, the RCS is used to manage a specific file, and Common commands are co and ci. The RCS uses the RCS directory in the previous Working path to store managed files.
Ci (check in) adds the source code to the RC source code repository. The version of each file added to the code library is 1.1.
After the ci is re-modified, the version of the file will increase to 1.2, 1.3, and ........
Co (check out) extracts the source file from the source code warehouse of the RCS. The default version is the latest version. If you need a specified version, you must use the-r option to specify it. For example:
$ Mkdir RCS: Build the source code warehouse of the RCS
Edit an object, such as hello. c.
# Include
Int main (void)
{
Printf ("Hello World \ n ");
Return 0;
}
Then add it to the RCS Repository:
[Kerberos @ power zhyf] $ ci hello. c
RCS/hello. c, v <-- hello. c
Enter description, terminated with single '.' or end of file:
NOTE: This is NOT the log message!
> The in‑verion. Enter information about file changes.
>. End.
Initial revision: 1.1 the initial version is 1.1
Done
[Kerberos @ power zhyf] $
After a file is added to the source code repository, the RCS automatically deletes the file.
　　
If you need to modify the file, retrieve it from the Repository:
[Kerberos @ power zhyf] $ co hello. c
RCS/hello. c, v --> hello. c
Revision 1.1
Done
In this case, the retrieved file is read-only. If you need to edit the file, you need to lock the file to prevent conflicts with others' edits.
Use the-l (lock) option for lock removal.
[Kerberos @ power zhyf] $ co-l hello. c
"Hello. c", "v -->" hello. c "is extracted from the" hello. c "warehouse. The files in the warehouse end with" v.
Revision 1.1 (locked) indicates lock removal.
Done
Now, we can modify and edit the file.
For example:
# Include
Int main (void)
{
Printf ("Hello World \ n ");
Printf ("checkoutwithlock \ n"); Add the code
Return 0;
}
[Kerberos @ power zhyf] $ ci hello. c
RCS/hello. c, v <-- hello. c
New revision: 1.2; previous revision: 1.1 re-join to the repository, the file version increases to 1.2
Enter log message, terminated with single '.' or end of file:
> Check out with lock and modified it.
>.
Done
If you need the previous hello. c version, that is, Version 1.1, you can use-r to specify the file version to be retrieved:
[Kerberos @ power zhyf] $ co-l-r1.1 hello. c
Hello. c, v --> hello. c
Revision 1.1 (locked) extracts version 1.1
Done
You can try to use two locks for removal. At this time, the RCS will prompt a warning message.
[Kerberos @ power zhyf] $ co-l hello. c
Hello. c, v --> hello. c
Revision 1.1 (locked)
Writable hello. c exists; remove it? [Ny] (n) Whether to overwrite the current hello. c
If n is answered, the retrieval fails. If yes, the option that overwrites the current file is-u, And the unlocked file is used for work. -F forcibly overwrites the files in the RCS warehouse at ci and overwrites the current files at co.
　　
In the RCS, keywords similar to macros are supported. After ci, these keywords are replaced with specific information by the RCS, such as the $ Id $ Keyword:
/* $ Id
*/
# Include
Int main (void)
{
Printf ("Hello World \ n ");
Printf ("checkoutwithlock \ n ");
Return 0;
}
After the ci is removed, the file will become:
/* $ Id: hello. c, v 1.3 2001/02/22 16:16:58 kerberos Exp kerberos $
*/
# Include
Int main (void)
{
Printf ("Hello World \ n ");
Printf ("check out with lock \ n ");
Return 0;
}
$ Id $ keyword is replaced by the file name, version, time, author, and code nature. If you use the-l option to retrieve the keyword, the name of the logon user will be added after Exp. In addition to the $ Id $ keyword, the following common keywords are also supported:
$ Log $: the modified Log information you provided.
$ Author $: Author of the version.
$ Locker $: Locker of this version
$ State $: the Status Exp (trial version), Stabe (stable version), and Rel (release version) of this version. The default value is Exp.
$ Date $: the time when the version is saved, in UTC time format.
$ Revision $: Version Number of this version
$ RCSfile $: RFM file name
$ Source $: full path name of the RCS
$ Name $: retrieve the symbolic Name of this version.
$ Header $: the combination of $ Source $ Revision $ Date $ Author $ State $ Locker $ has a diff tool in UNIX/Linux to compare the differences between the two files, rcsdiff can compare different files in different versions without removing the need to retrieve files, such:
Rcsdiff hello. c compares the differences between the current hello. c file and the latest version of the RFM repository.
Rcsdiff-r1.1 hello. c compares the differences between the current hello. c file and hello. c version 1.1.
Rcsdiff-r1.2-r1.1 compares the differences between version 1.1 and version 1.2 of the hello. c file.
With this command, you can easily make patch files between any version.
In addition, there are some other less commonly used RCS commands. For more information, see.
　　
Use CVS
Next, let's talk about the use and management of CVS.
　　
Before using CVS, you must specify the root path of CVS. Unlike the cross-site scripting (RFM) that works in the working directory. There are two methods to specify the CVS path. One is to use the cvs-d option, for example:
Cvs-d/home/kerberos/cvsroot specify/home/kerberos/cvsroot as the path of the CVS repository.
Another method is to use the CVSROOT environment variable (under bash ):
Export CVSROOT =/home/kerberos/cvsroot
　　
Regardless of the method, the path of the CVS Repository needs to be reset every time a terminal session is re-opened. You can add the above to the actual directory. in the bashrc file, after a terminal session is enabled, you do not need to reset the settings (for other environment variables ). If your CVSROOT environment variable already exists, you can use the cvs-d option to specify a CVS Repository different from that specified by CVSROOT. Then initialize the CVS repository and create some files and information required for CVS maintenance. CVS stores the information in the CVSROOT directory of the main directory of the CVS repository. These files, except for modules, are not required to be manually modified. The modules file defines the location of the CVS export module in the CVS repository, this is very convenient when exporting a deep directory from the CVS repository.
　　
Cvs init
After initialization, we use cvs import to import the directory structure of the development project that requires version maintenance to the CVS warehouse, as shown below:
After the directory structure of the project is established, the structure of the current testprj directory is as follows:
　　
[Kerberos @ power zhyf] $ tree testprj
Testprj
| -- Admin
| -- Doc
| -- Include
| -- Libs
'-- Src
| -- Include
'-- Main
　　
7 directories, 0 files
Cvs import has three parameters: the first is the module name of the directory tree in the CVS repository, the second is the publisher's identifier, and the third is the version tag of the project ). Next, we import testprj to the CVS repository and use the testprj Module name.
[Kerberos @ power testprj] $ cvs import testprj KERBEROS INITVER
　　
After executing the command, CVS will call the editor specified by CVSEDITOR to allow you to input logs. If CVSEDITOR is not defined, vi is called by default. You can use the export command to specify the editor you like. After entering the log, CVS imports the current directory structure into the CVS warehouse and uses the testprj Module name. When exporting files, you can use
Cvs co testprj to export.
"/Tmp/cvscVxZnW" 5L, 242C written
Cvs import: Importing/home/zhyf/cvsroot/testprj/admin
Cvs import: Importing/home/zhyf/cvsroot/testprj/libs