Document No .: SCM / STD-CVS
CVS Operation Manual
V1.0.1
Foreword
The full name of CVS is Cuncurrent Versions System, which is a GNU software package developed by INTERSOLV. It is a version control tool based on TCP / IP protocol and is also one of the most important development tools of the Open Source. The CVS uses the Client / Server structure, which is a maintenance tool based on the RCS system. It expresses independently of the storage of the source file and the user's workspace, expands the recovery submission function of the RCS in a certain mode, and makes it It is conducive to parallel development and is a version control system.
CVS opposes the mechanism to lock the file. CVS takes multiple users to edit a file at the same time, and then solve this problem. Assume that due to insufficient communication, the user must handle the conflict after handling the CommT. In this case, the developers of conflict must work to communicate sufficient communication to avoid conflict again.
In theory, CVS can maintain the development of any text documentation, not limited to programming. CVS uses a Copy-Midify-Merge change table to support the simultaneous access and modification of the file. There are two ways to use CVS: First, this machine is used, one is remote execution.
The command format of CVS is:
CVS [CVS Options] CVS-Command [Command Options]
Help information of CVS:
CVS -H Command
Revised page
serial number
Chapter name
Revision
Revision date
Before the revision
version number
Afterwards
version number
Revision
Approvers
1
create
2003-6-25
V1.0.0
Yu Yu
2
All chapters
Content adjustment and revision
2003-9-15
V1.0.1
Yu Yu
table of Contents
Revised page. 2
Purpose. 6
Basic terminology. 7
First, install CVS 10
1. Installing the CVS server on Linux / UNIX. 10
1.1 Download and install the CVS server. 10
1.2 Set up the CVS Warehouse (Repository) 12
1.3 CVS related settings. 12
2, installation of the CVS client. 14
2.1CVS client installation and setting on Linux / UNIX. 14
2.2wincvs installation and setting. 14
2.3TORTOISCVS installation. 17
3, distributed synergistic development with CVS. 17
Second, the basic command of CVS. 18
1, check in (import). 18
2, check out (Checkout). 20
3. View difference (DIFF) 20
4, merging your changes (UPDATE 22) 22
5, check the submission of the operation log (log) 24
6. Submit your modification to CVS 28
7, increase, delete files or directories (Add / Remove) 29
8, rename it. 32
9, write a good log entry. 33
10, handle conflict (Conflict). 33
11. Clear local work copy (Release) 34
12. Abbreviation for the CVS command. 34
Third, the basic operation of WinCVS. 36
1, check. 36
3, check out. 37
4, get the modifications of others from CVS. 38
5, resolve conflicts. 39
6, submit your changes to CVS. 40
7, check the modification. 40
8. Tag tags for files. 41
9, increase files and directories. 41
10, delete files and directories. 42
11. Retrieve the deleted file. 43
12. Move or change the file and directory. 43
13, branch. 44
14, select a branch work. 44
15, merge from the branch. 45
16, return to the development main line. 47
17, who is editing the file. 47
Fourth, TortoiseCVS basic operation. 49
1, Checkout 49
2, UPDATE 52
3, commit 53
4, Add 54
5, Create New Module / Repository 55
6, TAG / Label 57
V. Version control via CVS. 58
1. Revision and release concept. 582, label. 58
2.1 Creating Tags (Tag) 59
2.2 Version of the tag. 60
2.3 Adhesive tags (Sticky tags). 61
2.4 Delete the label. 62
2.5 Movement Tags. 62
2.6 Rename the label. 62
3, branch. 63
3.1 Creating a version branch (tag -b) 63
3.2 Access branch. 64
3.3 Determine on that branch. 64
3.4 Merge of version branch. 65
3.5 Clear the bugs of the release of the release take the whole process of branch, merge. 65
4, release source (export). 66
Sixth, basic flow charts of CVS operations. 67
Seven, CVS advanced operations. 68
1, define the CVS module. 68
2, CVS and binary files. 69
2, interaction between CVS and Build system. 71
3, how to restore the file that has been deleted. 71
4, version retrans. 72
Method 1: First update to the latest version, and then remove the old version to re-submit. 72
Method 2: Update command with -J. 73
5, merge and keywords. 74
6, backup and movement of the CVS warehouse. 76
Eight, CVS limitations. 77
Appendix. 79
purpose
After reading the document, I hope the reader can master the following skills:
1. How to install CVS on different operating system platforms;
2, the basic use of CVS.
See http://www.cvshome.org
Note: This document assumes that users are familiar with basic LUNIX / UNIX operations.
Basic term
Client / Server structure:
CVs work in client / server mode, all users perform CVS operations on the client, and all commands are performed on the CVS server.
CVS warehouse (Repository):
Also known as Master Copy is where the CVS system saves software resources. All versions of all files in all items are saved in this warehouse.
On the CVS server, a source warehouse is called a repository, and multiple repository can be run on a server, each repository is completely independent, and there are different user lists and access rules. Under a repository, the file is organized according to the Module, each module is equivalent to a project, which is substantially equivalent to the Project in Source Safe.
Work Copy:
From the CVS server side, the code copy is saved on the client computer we are using. A project has multiple work copies during development. A typical situation is a development team in developing a project. All team members share the same CVS server, share the same CVS warehouse, share the same version of the project in the CVS warehouse, but each group Members have a copy of their own work. Everyone's work copy is independently modified independently during the work. In most cases, these work copies are different. The independence of work copies prevents mutual interference in collaborative development, but it also brings some problems:
1. Document update problem: A developer has the code updated, how to get other developers get his latest code
2. Collaborative Communication Problem: A developer's code is updated, how to let other developers know what modifications he did
Import (import) code:
The code that is not managed by the CVS is introduced into the CVS system, and it will be managed by CVS.
Check out code (create a copy):
Remove the code from the server, which is the process of creating a working copy. When the code is removed from the CVS server, the CVS checks the version of the file according to the user's request, and select the correct version to send to the user. Submit (commit) code:
Send the code to the server, COMMIT is called Check IN. The CVS server is to be checked when the code is stored in the warehouse, and do the corresponding record.
CVS log:
That is, log message, is the information used to record the content and purpose of each operation. When the operation is submitted and imported, the operator must provide some comment information, which is part of the log as part of the log. Log information can be easily viewed with a cvs log command. CVS logs are important for tracking software changes. For changes control, configuration audits, etc., log information is important for these management content.
Module module:
A directory layer. A software engineering is usually stored in a library as a single module.
version:
For a file, a developer has submitted a new version when submitting his modification to CVS; for the entire software project, a version is a snapshot that keeps changing the project on a certain point in time.
RELEASE Release: The version of the entire product
Revision Revision: The version of a single file. When you add a file to repository for the first time, it will have an initial revision that is 1.1, and will increase to 1.2, 1.3 ...
Branch:
Branch is a branch in a normal growth code tree. When you start, you have a primary branch. A Branch is ultimately either merged into the backbone or is either ended. Branch is usually used to debug. If this bug is fixed, the code to modify the bug should be merged to the main branch. A Branch may also experience the merger of multiple branches.
Tag tag:
TAG is used to identify the necessary information, a symbolic name given to a fileset in a specific period of development. You need to mark the main branch "Release 1.0" when you make an open release. This way you can return to this version in the future.
Update:
In a collaborative development environment, the latest changes made by others are taken from the CVS warehouse to your work copy, so that your work copy is consistent with the latest version in the warehouse, and is also consistent with the latest progress of the project. Update is a means of synchronizing each work copy. If you are only developing separately, this concept is useless.
Conflict:
In a collaborative development environment, a conflict occurs when the two developers have modified the same line of code of the same file and submit the CVS warehouse. Because CVS cannot save two files of two identical names in a project, it is only a result of one line of code, not two. This conflict requires developers to handle, and submit new versions that form release conflicts in the CVS warehouse.
First, install CVS
1. Installation of CVS servers on Linux / Unix
1.1 Download and install the CVS server
The CVS server is a service program that accepts a remote and local CVS command request, and the entire process of installation is performed by the superuser.
1.1.1
Install relevant security service procedures
Below, we choose a Linux server to confirm if the security service program SSH is installed. The host name (hostname) of this server is CVSHOST.
Confirm that SSH is installed, execute in a command prompt with a superuser identity:
$ rpm -q ssh
Confirm that the CVS server package is installed, perform the command prompt at the command prompt by superuser:
$ rpm -q cvs
CVS-
1.11.5
If the system gives the information similar to the above, you can skip this section and go directly into the next section. If the system gives a message that "Package CVS IS Not Installed" (CVS software is not installed), you can download the source code compressed file in the RPM format or .tar.gz format.
The authoritative website released under Linux is www.openssh.org, enter the command prompt state under the Linux system, run the su command, enter the super user password, enter the RPM file or .tar.gz compressed directory.
If you download the RPM package, you can use the following command to install:
$ rpm -i ssh * .rpm
If you download the source package, you can first remove the package, then enter the SSH directory to install.
$ TAR -VXZF SSH * .TAR.GZ
$ CD SSH *
$ ./configure
$ Make
$ make Install
If no error message appears, the SSH is installed successfully.
If the server is set on UNIX, you need to install the following servers before installing the CVS server:
a) Install the ZLIB package: ZLIB-
1.1.4
-Vols.tar
Zlib is a general-purpose compression library, providing a set of In-Memory compression and decompression functions, and detects the integrity of the extracted data. ZLIB supports files that read and write Gzip (.gz) format. OpenSSH uses the ZLIB library as a compression engine.
The Zlib package is installed with a Custom. There is no error message during the installation process, then the installation is successful.
b) Installing a PRNGD package: prcNGD-
0.9.23
-Vols.tar
OpenServer uses PSeudo Random Number Generator daemon to get random number.
The PRNGD package automatically establishes a PRNGD user with a Custom installation, and requires a password. There is no error message during the installation process, and the installation is successful.
Add the following line at the end of the /etc/rc2.d/p88usrdefine file:
/ usr / local / sbin / prcnGD / usr / local / var / prcNGD / prcNGD-POOL &
c) Install OpenSSH software package: openssh-3.4p1-vols.tar
Many network programs, such as Telnet, RSH, Rlogin or Rexec, use the plain text to transfer passwords and secret information, so any computer can be used to listen to communication between these programs and servers using a computer connected to the network and get a password and Secret information. OpenSSH is those outdated, unsafe remote login programs such as: telnet, rlogin, RSH, RDIST or RCP alternatives.
The OpenSSH package is installed using a Custom. This Platform Does Not Support Both PrivileGE Separation and Compression Compression Disabled can be securely ignored safely, but compression cannot be used.
1.1.2
Install CVS server
If it is a file in the RPM format, run:
$ rpm -i cvs * .rpm
If it is .tar.gz compressed format file, assume it as cvs-
1.11.5
.tar.gz:
$ GZIP -D CVS-
1.11.5
.tar.gz
$ TAR-XVF CVS * .tar
$ CD CVS-
1.11.5
$ ./noautomake.sh
$ ./configure
$ .make
$ make Install
After the installation is over, if the system does not give any error messages, your CVS server has been installed. 1.2 Set the CVS Warehouse (Repository)
After installing the CVS server software package, you need to select CVS to save software resources such as software resources and CVS's system files such as users, which is where the CVS warehouse is selected. The content of the CVS warehouse is logically ten file version of the tree, each file has its own version entity, CVS only stores changes between different versions, saving space.
If you choose the SCMRepository directory as the location of the CVS warehouse, execute:
$ MKDIR SCMRepository
$ CD SCMRepository
Below, we will establish a directory for software resources such as all item source code in the CVS warehouse.
$ mkdir myproject
After determining the location of the CVS warehouse, the CVS server is initialized. Before initialization, you can set the cvsroot environment variable (see settings to CVSROOT in the CVS environment settings), point to the absolute path of the repository, then call the cvs' init command. It can also be used as follows:
$ cvs -d $ home / scmrepository init (Note: The path is set according to the actual setting)
Many CVS commands allow this way to specify the root directory of CVS.
The working copy of your source code can also exist different from the CVS library machine; this way CVS operates in a Client / Server mode. You first run a computer with your own catalog, it is called a client; then tells it that you will connect to a computer with a CVS library, it is called a server. Typically, in addition to the CVS library name format, using the remote CVS library, there is no difference between other aspects:
: Method: [[User] @] Hostname [: [Port]] / Path / TO / Repository
1.3 CVS related settings
Step 1: Establish a CVS group and CVS users
In an integrated development environment, it is recommended that the project manager establishes CVSADMIN users for CVS management. The project manager needs to be recommended to create a group (following the CVS group) and the CVS user corresponding to the project group member.
Step 2: CVS administrator and ordinary user permission settings
CVS's permission setting basically follows the following rules:
1. CVS users must have read rights to $ cvsroot / cvsroot directory and all files;
2. CVS users must have write access to the History file under the $ cvsroot / cvsroot directory;
3. CVS users If you want to have the right to modify the information such as code (the module called module in the CVS system), you must have write access to this directory.
4. In the UNIX / Linux system, read / write permission to a directory must include read rights and executable permissions for all superior directories.
The suggestions for users and permission settings are as follows:
1. In the project development environment, establish a cvsadmin user separately, establish a CVS source code library in this user environment, managed by the project manager;
2. Establish different groups (GroupAdd), such as the CVS administrator group, CVS regular account group, depending on the needs of management and different projects, such as CVS administrators groups, CVS ordinary account groups;
3. According to the project needs to establish a CVS ordinary account corresponding to the project, the user belongs to a different group, so that the project member can use the CVS to operate, the policy settings follow the above rules;
4. Establish different directories according to different projects in the source library, in principle, one top directory, and permission settings for the directory, make the group attribute of the directory corresponding to it to control it. Group, for non-project users to make the necessary security settings, such as read reading, etc. 5. Ensure that most CVS users have UNIX system level permissions to the CVSROOT directory in the warehouse.
Step 3: CVS environment settings
1, set the cvsroot environment variable
The most important thing in the client configuration is the setting of the cvsroot environment variable. The format is:
: EXT: Username @ hostname (or IP address): CVS Warehouse Path
The meaning of each field is described below:
n "Hostname" is the host name of the CVS server, which is replaced with the IP address of the CVS server.
n "Username" is "you" - the user's account / user name using the CVS client. Note that this username does not have any inevitable relationship with your account / username on the client. The CVS client program sends this username to the CVS server, and the CVS server requires the user to enter his password on the CVS server and certify.
n "CVS Warehouse Path" is another parameter sent to the server in the CVS client. Since there may be multiple different warehouses on the CVS server, if this warehouse path is not specified, the CVS server does not know which warehouse wants to access. In fact, the "hostname" (or IP address) of the CVS server and the warehouse path uniquely determines a directory on a computer on the network. This directory is the directory where you want to visit the warehouse.
n "EXT" is a CVS remote access method.
Summary above, this information is the client / server mode of CVS. If there is no such information, the CVS client cannot initiate and complete the connection to the CVS server.
a) For Linux systems:
(SH / BASH) Open the $ home / .profile or $ home / .bash_profile file with the editor, add:
EXPORT CVSROOT =: ext: jyang@192.168.1.100: / src / master
(CVS administrator: export cvsroot = / src / master)
(CSH) Open the $ home / .cshrc file with the editor, add: Add:
Stenv cvsroot =: ext: jyang@192.168.1.100: / src / master
(CVS administrator: setENV cvsroot = / src / master)
b) For UNIX systems, edit the .profile file, add as follows:
Cvsroot =: EXT: cvsuser1@192.168.1.100: $ homen / scmrepository
(For CVS Administrators: Export CvsRoot = $ Home / SCmrepository)
Export cvsroot
2, set the environment variable CVS_RSH = SSH, the setting mode, and the same.
3, add CVS path in the PATH variable / usr / local / bin
4, add, save the modification, and turn off the editor.
5, run. .Profile
6. Test if the configuration of the environment variable is correct, execute the following command:
$ Echo $ CVSROOT
: EXT: CVSUSER1@192.168.1.100: / usr / cvsadmin / scmrepository The above output is the same as the configuration, which proves that the configuration is successful. If the output is an empty line or other value, it indicates that the configuration is unsuccessful or has not yet taken. Recheck the previous steps. PATH, RSH_CVS is similar.
2, CVS client installation
2.1CVS client installation and settings on Linux / UNIX
The CVS package is the server / client integration, so the installation of the client is installed on Linux / UNIX installation.
The CVS client settings see the CVS environment settings.
2.2wincvs installation and setting
Step 1: Install TCL / TK (optional)
Step 2: Install Python (optional)
Step 3: Install SSH in the Windows End of the package, available in www.ssh.com has a package to download. It is best not to use the default path when installing SSH, install it to the D: / SSH or similar path. The installation process is simpler, here is slightly. Restart the system based on the prompt.
Step 4: The Windows client uses WinCVS, available in www.wincvs.org, available package downloads. The installation method is very simple, here is slightly. Figure 1 is the pattern after WinCVS installation, please pay attention to its command results output window, followed by it.
command
result
Output
window
Figure 1: WinCVS window pattern
Step 5: Configure the WinCVS client.
After installing the client, the most important step is the configuration of the client. The purpose of configuring the CVS client is to let it find the server to access according to the configuration information and a specific repository on the server. Because there are multiple different warehouses on one server, the path to the warehouse is also one of the contents of the client configuration. The CVSRoot environment is described in the CVS environment settings.
Examples are as follows:
Figure 2: WinCVS Configuration Window
Open the following menu adminàpreferences.
After a window shown in Figure 2, in the General (Default) page, Authentication Select SSH, click the SSH Client Tomb, enter the execution path of the SSH Secure Shell, select SSH2, click OK, Path Input / USR / cvsadmin / scmrepository (ie the absolute path of the CVS warehouse), Host Address input 192.168.1.100 (IP address of the CVS server), User Name Enter the username, such as CVSUSER1 (using the username on the CVS server). Then, click the CVS tab, set the "Home Folder" item to a valid directory on a local drive, such as "C: / CVSDIR", then select the "OK" button. Configuration is completed.
In the "Globals" page, the configuration is mainly to pay attention to these options:
First, Checkout Read-Only Don't choose, otherwise, the source code from Checkout will not allow users to perform
Modify, and this option is selected by default;
Second, prune (transove) EMPTY DIRECTORIES should not be selected, otherwise, the empty directory will be automatically deleted;
Third, there is no special requirement for general configuration, put Dirty Files Support, Supply Control When Adding
Select the TCP / IP Compression option.
2.3TORTOISCVS installation
This process is simpler, which is not described in detail here. Specific use sections the basic operation of TortoiseCVS.
3. Distributed Co-Development with CVS After completing the above configuration, the CVS warehouse has been accessible from any of the terminals that can be accessed to this installation CVS on the network. This shared network warehouse is an open source code. When using CVS inside a company, the CVS warehouse should be placed in the company's firewall, and the employee can access the CVS warehouse from any of the company's interior. If you need to access the CVS warehouse from the client party, the secure approach is to create a VPN network to ensure that remote access is performed in a manner, data encryption.
Second, the basic order of CVS
Note: 1. In the SSH authorization mode, when the CVS command is executed, you need to enter the password of the remote user.
2, pay attention to the clock synchronization of the server and the client, otherwise the submitted ignored situation may occur.
1, check in (import)
When you start using CVS, you may have several projects can be managed using CVS. In this case, the easiest way is to use: import command. We have to join the file that needs to be managed to the warehouse and name it. The use of the cvs command import is as follows:
$ CVS [-D Warehouse Absolute Path] Import -M "Write Some Comments Here" Project_name vendor_tag release_tag
-m: Specify a note, if you do not use the -m parameter to record a log information, CVS will call an editor (usually VI) and prompt to enter information.
Project: Warehouse Name
Vender_TAG: Development Trademark
Release_tag: Version publishing tag, cannot bring $,.;: @ these special symbols.
Import all source files and directories in the current directory to the $ cvsroot / project_name directory after execution.
-I name - The name of the file ignored when imported. You can specify multiple files. This option supports wildcard. * .foo means that all files ending with .foo are ignored.
The following files and directories are ignored by default:
.
.
. # *
# *
*
_ $ *
* ~
* $
* .a
* .bak
* .Bak
* .elc
* .exe
* .ln
* .o
* .obj
* .olb
* .old
* .orig
* .rej
* .so
*.Z
.del- *
.make.state
.nse_depinfo
core
Cvs
CVS.ADM
Cvslog. *
RCS
RCSLOG
SCCS
tags
Tags
Can use -i! Options are forbidden to ignore these files and directories. E.g:
$ cvs import -i! -m "importing the universe" Proj Vendor Vendor_0
The above command will import all files under the current directory tree, including those that will be ignored.
-I! Options Clear a record of the ignored file type. So in -i! The -i option does not work, but -i! The -i option is still valid. therefore:
$ cvs import -i! -i readme.txt -m "some msg" theirproj the them_0
Unlike the following command:
$ cvs import -i readme.txt -i! -m "some msg" theirproj the them_0
The former ignores the readme.txt file, the latter will import this file.
Note: IMPORT is relative to the current directory and all its subdirectories. The CVS command for the text type file, see the CVS and binary files for non-text type files. After the first export, it is not synchronized by CVS Checkout, but is to enter the version of the specific file in the Project_name directory that has just been exported to CVS Checkout Project_Name. 2, check out (Checkout)
According to the working principle of CVS, once the code is loaded (or "submit") to the CVS warehouse, we should not use the original source code. If you want to change the code, we should first put the code from the Knowledge Base "Check Out" to a separate working directory, then make the necessary modifications, and then resubmit the modified code to the warehouse. For example, suppose you currently work in HTTPC:
$ CD
$ cvs checkout httpc
CVS Checkout: Updating HTTPC
U httpc / .cvsignore
U httpc / makefile
U httpc / httpc.c
U httpc / poll-server
The command CVS Checkout HTTPC is: "Treasure the source tree called HTTPC from the warehouse specified by the CVSROOT environment variable." CVS put the tree in the subdirectory named "httpc":
$ CD HTTPC
$ ls -l
Total 8
DRWXR-XR-X 2 Jimb 512 OCT 31 11:04 CVS
-rw-r - r - 1 Jimb 89 Oct 31 10:42 Makefile
-rw-r - r - 1 Jimb 4432 OCT 31 10:45 httpc.c
-RWXR-XR-X 1 Jimb 460 OCT 30 10:21 Poll-Server
Most of these files are your work copy of your HTTPC source.
We can check all or part of the current source tree to the working directory, then modify the source code in the working directory. There will be a CVS / directory in the working directory, but we don't need to pay attention to it.
3. View difference (DIFF)
CVS DIFF compares and displays the differences between the two versions. If you do not use any options, the CVS Diff command compares the library library version (Base Revision) and the work copy (often unbeetated) files. The library version refers to the last version submitted from the local work copy in the warehouse. There may be a new version in the warehouse you need to pay attention to. It is possible that other users have submitted new files, while local working copies are not updated.
-B: Ignore the blank line. Ignore only the space of the space is ignored.
-b: Ignore the repeated space. This option looks the space as the same and ignores the space of the row. This option makes the DIFF command to merge the consecutive space in the input into one and delete the last space of each row (see -w option).
-c: output in a DIFF format containing the context. By default, there is a difference between each of the comparison results that there is a 3-line context (because the patch requires at least two contexts).
-C Num: and -C option work the same effect, and the number of contexts is determined by the parameter NUM.
-I: Make a blurred comparison, do not distinguish uppercase and lowercase letters.
-u: Output comparison results in a unified DIFF format.
-w: Ignore all blank characters, even in another file contains a blank character, it is ignored when another file does not contain blank characters. -w can be seen as the enhancement of the -b option.
Have you forgotten if HTTPC.c has been changed, and you want to query the change of this file.
$ CD HTTPC
$ CVS DIFF HTTPC.C
This command DIFF can check the difference in version of the version of HTTPC.c and the version of the working directory.
$ CVS DIFF -U -R0.5 Authorsindex: Authors
============================================================================================================================================================================================================= ==================
RCS file: / home / hahalee / cvs / hftpd / authors, v
Retrieving Revision 0.5
Retrieving Revision 0.6
DIFF -U -R0.5 -R0.6
--- Authors 2000/04/07 10:46:02 0.5
authors 2000/04/07 14:05:57 0.6
@@ -1, 3 1,4 @@
ah! let me in!
So Then, WHO CAN't Spell
DEVELLOPPOPOTAMUS?
QUITE A LOT OF US.
There is also an RDIFF for generating the Patch between two different releases.
RDIFF is similar to the DIFF command, which is only in the repository in the repository, so there is no need to work. The purpose of this command is to get the difference between the two different versions of the project, and its format is suitable for the input of patch programs (so you can publish patch files to users who need to upgrade).
Note: The operation mechanism of the patch program has exceeded the scope of this article, but it should be noted that if the patch file contains the DIFF result of the file in the subdirectory, you need to use the PATCH command with the -P option to correctly apply These differences.
$ cvs -q rdiff -s myproj
File myproj / random.txt is new; Current Revision 1.4
File myproj / readme.txt change from revision 2.20
File myproj / bar is new; Current Revision 2.3
-t - Displays the difference in two versions of each file. This is a convenient way to determine the latest changes in the project. This option is not compatible with the -d and -r options.
4, merging your changes (UPDATE)
Once CVS creates a working directory tree, you can edit, compile and test the files contained in the directory through the usual way - they are just a file.
Because each developer uses their own work catalog, your changes to your work directory do not automatically become visible to other developers in your development group. I don't get ready, CVS will not announce your changes. When you have completed the test of your changes, you must submit them (commit) to the warehouse so that they can use other members of the group to submit your changes to CVS.
However, if another developer has changed the same file you change, or the same line, what should I do? Whose changes should be successful? In general, it is impossible to automatically answer this question; CVS undoubtedly no ability to make such judgments. Thus, CVS requires your source to keep synchronization with any changes to other group members before you submit your changes.
"CVS Update" tells you what it is doing by printing the single character, space, and file name, what to see; as shown in the following example: # CVS Update -dp
Distfiles
? package
? PROFILES
"CVS Update" uses "?" characters to indicate these special files found in the local copy. They are not the formal part of the repository, nor is the part to be added. Here is a list of all other single-character information messages used by CVS:
U [PATH]
Create a new file in the local repository, or update your files you have not moved.
A [path]
This file is scheduled to be added, when using "cvs commit", it is officially added to the repository.
R [PATH]
Like "a", "R" lets you know the file plan to remove it. After entering "cvs commit", the file will be removed from the repository.
M [PATH]
This means that you have modified the file; and there is a possible resource library has successfully merged into the file.
C [PATH]
It indicates that there is a conflict in this document, and it needs to be manually modified before using the "CVS Commit".
$ CVS Update
CVS Update: Updating.
U Makefile
RCS file: /u/src/master/httpc/httpc.c ,v
Retrieving Revision 1.6
Retrieving Revision 1.7
Merging Difference Between 1.6 and 1.7 INTO HTTPC.C
M httpc.c
Let's take a line in one way:
U Makefile
"U file" formal line of line of lines of this file has been explicitly updated (Updated); another person has changed this file, and CVS has copied the modified file into your home directory.
RCS file
Retrieving Revision 1.6
Retrieving Revision 1.7
Merging Difference Between 1.6 and 1.7 INTO HTTPC.C
These messages indicate that some people have changed "httpc.c"; CVS combined with your changes and did not find any conflicts on any text (Conflict). Number "1.6" and "1.7" are revision numbers that identify specific points in the history of the file. Note that CVS just merges the changes into your work copy; the warehouse and other developers' work directory are not disturbed. To test the merged text, make sure it is effective.
M httpc.c
The "M File" form of the way is that the file has been modified (modified) and contains the modified changes to other developers. These are changes you need to submit. In this way, "httpc.c" now contains your modifications and other users.
Because CVS has merged other people's changes into your source, it is best to determine that the program can work. In you have made your source to keep up with the latest situations there, and do their tests, you can submit your changes to the warehouse and make them a group's remaining members. The only file that is modified by you is "httpc.c", but the list runs CVS Update to get the modified file from CVS is always reliable:
$ CVS Update
CVS Update: Updating.
M httpc.c
As expected, the only file mentioned by CVS is "httpc.c"; it said that the file contains changes you have not submitted. You can submit them like this: $ cvs commit httpc.c
At this time, CVS will start the editor and prompt you to enter the log message to describe the change. When you exit the editor, CVS will submit your changes:
CHECKING in httpc.c;
/ @rc/master/httpc/httpc.c ,v <- httpc.c
New Revision: 1.8; Previous Revision: 1.7
Now you have already submitted your changes, and they are visible to other members of the group. When another developer runs CVS Update, CVS will combine your changes to "httpc.c" into their working directory.
In addition, use the "CVS Status" command, we can check if the latest version of the specified file has been given, or obtain details of the specified file, see CVS_STATUS.
5, check the submission of the operation log (log)
Now you may be curious, other developers have made what changes "httpc.c". In order to view log entries for specific files, you can use the cvs log command:
$ cvs log httpc.c
RCS file: /u/src/master/httpc/httpc.c ,v
WORKING FILE: httpc.c
HEAD: 1.8
Branch:
LOCKS: STRICT
Access List:
Symbolic names:
Keyword Substitution: KV
Total Revisions: 8; SELECTED Revision: 8
Description:
The One and ONLY SOURCE FILE for the TRIVIAL HTTP CLIENT
----------------------------
Revision 1.8
Date: 1996/10/31 20:11:14; Author: Jimb; State: Exp; LINES: 1 -1
(TCP_CONNECTION): CAST Address Structure When Calling Connect.
----------------------------
Revision 1.7
Date: 1996/10/31 19:18:45; Author: Fred; State: Exp; LINES: 6 -2
(Match_Header): make this test case-insensitive.
----------------------------
Revision 1.6
Date: 1996/10/31 19:15:23; Author: Jimb; State: Exp; LINES: 2 -6
...
You can ignore most of the text here; the part to be carefully viewed is the log entry behind the first line. Assume that closer modifications are often more interesting, so these entries appear in the order of reverse annual month. Each entry describes a change in the file and can be parsed as follows:
Revision 1.8
Each version of the file has a unique revision number. It looks like "1.1", "1.2", "
1.3.2
.2 ", or even" 1.3.2.2.
4.5
"
. By default, the revision 1.1 is the first version of the file. Each subsequent revision gets a new number by adding the rightmost number.
Date: 1996/10/31 20:11:14; Author: Jimb; ...
This line gives a change date, as well as the user name of the person submitted; the remaining parts of the line are not interesting.
(TCP_CONNECTION): CAST ...
This is (quite obvious) log entries that describe the changes. If you actually want to view the changes you are discussing, you can use the CVS DIFF command. For example, if you want to view Fred as a change in the revision 1.7, you can use the following command: $ cvs diff -c -r 1.6 -r 1.7 httpc.c
Let's take a look at the meaning of each part before we look at the output of this command:
-c:
This option requires CVS DIFF to make people more understandable formats for its output.
-r 1.6 -r 1.7:
This tells the CVS to display the changes you want to turn your HTTPC.C's revision 1.6 to amendment 1.7. (By specifying the revision: -r 1.7 -r 1.6, you can even request a change to be reversed, as if they are being revoked (undo). This sounds strange, but sometimes it is useful.)
httpc.c:
This is the name of the file to check. If you don't give a specific file, CVS will generate a report for the entire directory. Below is the output of this command:
INDEX: httpc.c
============================================================================================================================================================================================================= ==================
RCS file: /u/src/master/httpc/httpc.c ,v
Retrieving Revision 1.6
Retrieving Revision 1.7
DIFF-C -R1.6 -R1.7
*** httpc.c 1996/10/31 19:15:23 1.6
--- httpc.c 1996/10/31 19:18:45 1.7
****************
*** 62,68 ****
}
! / * Return Non-Zero iff Header Is a Prefix of Text. Header Should Be
Null-terminated; len is the length of text. * /
Static int
Match_header (char * text, size_t len)
--- 62,69 ----
}
! / * Return Non-Zero iff Header Is A Prefix of Text, Ignoring
! Difference in case. Header Should Be Lower-Case, And
Null-terminated; len is the length of text. * /
Static int
Match_header (char * text, size_t len)
****************
*** 76,81 ****
--- 77,84 ----
For (i = 0; i { Char t = text [i]; IF ('A' <= T && T <= 'Z') T = 'a' - 'a'; if (header [i]! = t) Return 0; } It is worth noting that from the first two rows from *** and - the beginning; they describe older and newer comparison files. The remaining part consists of two bulk (hunk), and each bulk begins with a row of asterisk. Here is the first large block: **************** *** 62,68 **** } ! / * Return Non-Zero iff Header Is a Prefix of Text. Header Should Be Null-terminated; len is the length of text. * / Static int Match_header (char * text, size_t len) --- 62,69 ---- } ! / * Return Non-Zero iff Header Is A Prefix of Text, Ignoring ! Difference in case. Header Should Be Lower-Case, And Null-terminated; len is the length of text. * / Static int Match_header (char * text, size_t len) The text from the older version appears behind the *** 62, 68 ***; the text from a newer version appears behind --- 62,69 - line. Each pair of digital indicates the range of the display line. CVS provides contexts around the change and will actually affect the "!" Character. Thus, we can see that the single line of the upper half is replaced by the second half of the two lines. Here is the second large block: **************** *** 76,81 **** --- 77,84 ---- For (i = 0; i { Char t = text [i]; IF ('A' <= T && T <= 'Z') T = 'a' - 'a'; IF (header [i]! = T) Return 0; } This large block describes two rows that are inserted, they are marked with " " characters. In this case CVS omits the old text because it is extra. CVS uses a similar large block format to describe deletion. Another use of this command is to control the work copy with the warehouse. $ CVS Diff Test.c INDEX: TEST.C ================================================================================= RCS file: /src/master/test/test.c ,v Retrieving Revision 1.2 DIFF -R1.2 TEST.C 1A 2 > // Comment Added by CVS Tester Note that the output here is the output format of the UNIX DIFF command. among them 1A 2 Indicates that the original version of the first line (1) is added (A-Add) content, and this added content is the second line in the new version. Slightly complex output is as follows: 47C 54 --- > Void * three_func (void *); 65A 73, 80 > Case 'D': > IF (argc == 0) { > USAGE (); >} > Dbname = * argv; > Argc-- > Argv ; > BREAK; 86C 101 --- > Debug_flag = 1; 94A 110 > IF (! Debug_flag) Daemon (1,0); The output in the output is the original version of the original version, and the line starting with ">" is the new version of the content. "-" indicates the boundaries between the two versions. " 65A 73, 80 " The contents of the original version of Chapter 65 have been added, which are from Chapter 73 to 80 in the new version. 6, submit your modification to CVS (Commit) After modifying the code, we need to save your work outcomes (not in local storage, but in the warehouse saved to CVS), that is, submit the source code. After saving, we don't have to worry about finding our different versions of our different versions. Perform the following command to complete the submission source code: $ cvs commit -m "add string variable and header string.h" Test.c CHECKING in Test.c; /src/master/test/test.c ,v <- test.c New Revision: 1.2; Previous Revision: 1.1 DONE Here, the -m is followed by CVS comments. CVS enforces the user to write a comment message at any time of any submission (IMPORT), etc. Each submission, give a very clear habit of a very clear annotation when importing operations, is very important for tracking software, it is difficult to remember that the code has been submitted by three months or even 1 year ago. What modifications, if there is no clear comment, the maintenance code will become very difficult later, and the relevant information is known to write a good log entry. CVS supports us using Chinese as an comment message. If we enter Chinese comments on a Windows client (or support Chinese Enter a UNIX / Linux client), we will become easier to check, maintenance will become easier. If you are not at the command line, then CVS will start the default editor (Note: You can change the editor settings by setting the cvseditor environment variable), please enter the comment, only the user saves comments and exits the editor, submit the operation success. The following figure is an example of an output window: Waiting for user input CVS window If you are submitted, "Up-to-Date Check Failed" is prompted to indicate that the file has not been updated to the latest version, if the file version in the CVS source library is inconsistent with the version in the work copy is inconsistent This warning will appear. CVS only allows for submission based on the latest version of the source library. How to update the source code for your changes. Note: Many of the CVS are confirmed and modified by CVS Commit. It is best to modify only one file each time. Before confirming, users need to fill in the modified comments to help other developers understand the causes of modifications. Note: The CVS itself is not a "Modification Tracker", so you need to achieve improved change tracking management, you need to combine CVS and a "modification Tracker" or "bug tracker". 7, increase, delete files or directories (Add / Remove) Before adding a file to the module or directory, you must first get a version of the work copy, and then work in a copy. CVS is based on other modifications to create and delete files, which records such an event in the history of the file. That is, the CVS record directory and the history of the files they contain. To add files to your project, you must create this file first, then use the cvs add command to add tags to it. Thus, the next time the use of CVS Commit will increase the file to the warehouse. For example, here you can add a readme file to the HTTPC project: $ ls CVS Makefile httpc.c poll-server $ vi readme ... ENTER A Description of HTTPC ... $ ls CVS Makefile Readme Httpc.c Poll-Server $ CVS Update CVS Update: Updating. Readme --- CVS Doesn't Know About this file yet. $ CVS Add Readme CVS Add: Scheduling File `Readme 'for addition CVS Add: Use 'CVS Commit' to Add this file permanently $ cvs update --- now what does cvs think? CVS Update: Updating. A readme --- The File is marked for addition. $ cvs commit dd CVS Prompts you for a log entry ... RCS file: / u / jimb / cvs-class / rep / httpc / readme, V DONE Checking in readme; / u / src / master / httpc / ready, V <- readme Initial Revision: 1.1 DONE The following command adds the directory newdir into the CVS warehouse: $ cvs add newdir Note: The Add directory only take one step instead of two steps. CVS cannot know the time of the directory added. CVS treats the deleted file in a similar manner. You must first delete the file in your work copy, then use the CVS Remove command to do it to delete the tag. Running CVS Commit will remove the file from the warehouse. It is worth noting that even if the file is to be deleted, it should be saved, that is, say, to submit the deleted version to the CVS warehouse as a new version. Submitted by the CVS Remove tag that the file will not destroy the history of the file. It just adds a new revision, marked as "do not exist". The warehouse has the previous record of the previous content and can be restored when needed - for example, by CVS DIFF or CVS log. If the user deletes the file, you can use the add command to cancel the removal operation before submitting the rendence. $ ls CVS ja.h oj.c $ rm oj.c $ cvs remove oj.c CVS Remove: Scheduling Oj.c for Removal CVS Remove: Use 'cvs commit' to remove this file permanently (CVS Remove -f will be above two steps and step) $ cvs add oj.c U oj.c CVS Add: Oj.c, Version 1.1.1 .1, resurred If you realize an error before running the Remove command, you can use the Update command to recover the file: $ rm oj.c $ CVS Update Oj.c CVS Update: Warning: Oj.c Was Lost U oj.c Since CVS does not have to manage and control the directory, the delete directory is not like deleting a directory, without a direct deleting directory that can complete this task. Deleting a directory method is to delete all files in the directory. Users cannot delete the directory itself, and there is no way to do this in CVS. You can use the -p option in the CVS Update or CVS Checkout command to let CVS delete the empty directory in the working directory. $ cd newdir $ cvs remove -f new.c $ CD .. $ CVS Update -P At this time, the newdir directory disappears in the current working directory, pay attention to Remove not to delete the CVS system directory. There is a related phenomenon here. Need to note: When the CVS Update command is executed, the CVS does not automatically take out the directory added to the warehouse after the work copy is created, and the solution is to use the -d parameter when performing CVS Update. $ CVS Update -d Note: Delete, the most convenient way to move the directory is to move the administrator directly, and remove the corresponding directory in CVSROOT to modify the directory, require its developers to re-export project CVS Checkout Project_name or with CVS Update -DP synchronization. 8, rename CVS is more supported by rename or movement of files and directories. There are several policies to rename files; the easiest is to quickly rename files in your working directory, and run CVS Remove for old names, run CVS Add in new names. The disadvantage of this method is that the log entry for the old file content will not be entered to the new file. $ mv old new $ CVS Remove Old $ cvs commit -m "removed for renameing" OLD $ cvs address $ cvs commit -m "renamed old to new" old new This is changed to New. Now the problem is to view the log file, you must remember two different file names, you can build the old file name in the new file first edition, then encounter " "Renamed Version" View the log of the old file. Note: More direct means is to rename ", V" directly at the server side, note that you should be confident that this command is used when doing this. For the rename of the directory, and the file is similar: $ mkdir ndir $ mv newdir / * ndir $ cvs -q remove newdir / * $ cvs -q commit $ cvs -q add ndir $ cvs -q commit ndir 9, write a good log entry If we can use the CVS Diff to get the actual text of the change, why should I write a log entry? Obviously, the log entry can be shorter than the patch and allow the reader to obtain a comprehensive understanding of the change without having to deepen its details. However, a good log entry should describe the cause of developers to make changes. For example, a bad log entry written for the revised version 1.7 shown above: "This is accurate, but it is completely useless; CVS DIFF provides the same information, more clear. A better log entry is: "This test is not sensitive to the case." Because other people will have a general understanding of the code, so that it is clear. 10, handling conflict (Conflict) As mentioned above, the CVS Update command combines the changes made by other developers into your working directory. If you have modified the same file and other developers, CVS combines their changes and your changes. It is easy to imagine how this is working when the different area of the file is applied to the file. But what happens when you have modified the same line and another developer? CVS said this situation is conflict and left it to you to eliminate it. For example, suppose you have just added a wrong check to the host name lookup code. Before submitting your changes, you must run CVS Update so that your source is synchronized: $ CVS Update CVS Update: Updating. RCS file: /u/src/master/httpc/httpc.c ,v Retrieving Revision 1.8 Retrieving Revision 1.9 Merging Differences Between 1.8 and 1.9 INTO HTTPC.C RCSMERGE: WARNING: CONFLICTS DURING MERGE CVS Update: conflicts found in httpc.c C httpc.c In this example, another developer has changed the same area of the file you change, so CVS will complain about conflict. Do not print "M httpc.c" as it usually do, print "C httpc.c" to indicate a conflict in this file. To eliminate conflicts, open the file in your editor. CVS tag conflict text: / * Look Up The IP address of the host. * / Host_info = gethostbyname (Hostname); <<<<<<< httpc.c IF (! Host_info) { FPrintf (stderr, "% s: host not found:% s / n", progName, hostname; Exit (1); } ======= IF (! Host_info) { Printf ("httpc: no host"); Exit (1); } >>>>>>> 1.9 SOCK = Socket (PF_INET, SOCK_STREAM, 0); It is important to understand how CVS determines conflict, and CVS simply treats its source code as a text file tree. CVS's understanding of conflicts is strict in the sense of text. The solution to the conflict is to edit the file, and the partial conflict will be rewritten. For logical issues, CVS will not find it at all. So the process of dealing with the version should be combined with the need in software development, and also require communication between group members. 11. Clear local work copy (Release) After the source file is necessary, you can use CVS Release -d to delete local work copies and notify other developers this module is no longer used. The release command is usually told to tell you how many sources in the working directory have been changed, and then confirmed to you before deleting or making changes in the historical file. Under the case of security, you can press N RET. example: $ CVS Release -d Print -d: Delete PRINT: Directory 12, abbreviation for cvs command Since the CVS command needs to typing often, each command has an abbreviated form. The abbreviation form of the most common CVS command is corresponding to the prototype: Command prototype Command abbreviation CVS Checkout CVS Co CVS commit CVS CI CVS Update CVS UP CVS Status CVS ST Third, WinCVS basic operation Note: When executing the CVS command, a CVSNT console interface is jumped, requiring the password of the remote user. 1, check in 1) As shown in the figure, the folder to be imported in CVS is selected. 2) Select Remote-> Import Module menu 3) In the pop-up file dialog box, according to the different requirements of the listed file, select the file, click "Edit" to set, make sure the files mentioned correctly set text or binary, and if it is submitted, it is ignored. OK is determined; 4) Click "Continue", enter the setup dialog box in the Import Settings, and enter the module name as the top-level directory name of the module in the future; 5) Enter your name or company's name (no space) in the Vendor Tag Manager. 6) Enter the version information in the Release Tag Release Tag Bar; 7) Enter log information; 8) Click OK button WinCVS then inputs the entire directory structure into the CVS server. Note that there is no change in your local file in the input operation. That is, after the input, your local copy is not placed under version control. You need to work before working on your version control source file: 1) Remove your original directory. 2) Use the copy of the new module using the checkpoint. 3) There is also an unimportant file that is copied back to you. You can start project work in version control now. 3, check out A module is obtained from the CVS server for the first time, referred to as an inspection. A module is detected from the library that creates a directory layer constituting the module locally. Use the following steps to perform check: 1) Select Remote-> Checkout Module menu 2) In the pop-up file dialog box, fill in the module name to be checked out on the remote server, select the directory you want to store, and a directory named module name will be created under the directory you selected. 3) Checkout Options Page: A checkup setup dialog box is used to set the checkout operation; 4) General Page: General default settings; 5) Select the globals box and set up items as required, which is generally default; 6) Click the OK button 4, get someone else 's modification from CVS Sometimes, you may ask for a copy of others to the copy to your local use. From the server to modify the local process called update. You can update a single file, the selected file set, or a whole directory layer. Perform the following steps to complete the update. Before modifying local files, it is best to update files from the server, because multiple people operate the same file, and there is no timely update to cause conflicts. If the version of the ALA is the same as 1.2, the version of the revised submission is 1.3, and B is not updated at this time, and the submission is modified on the basis of local 1.2. At this time, there will be a conflict as follows, and the conflict file will be displayed. 1) Select the directory or file you want to update in the WinCVS right tree box; 2) Right-click on the selected directory or file, select the Update Selection Update menu item 3) Confident Create Missing Directories That EXIST in the repository is selected 4) Click the OK button. Other people's modifications will be merged into your file and keep your changes to the same file. Update has no effect on the library. 5, resolve conflicts The CVS server occasionally reports conflicts when you update your local files from the library. Conflicts occur when two or more developers have modified the same file. CVS knows nothing about your project, so resolving the conflict to the developer. Once a conflict occurs, you have to open a problem with the problem, and the search begins in <<<<<<<. The conflict area has such a mark: <<<<<<< file name Your modification ======= Code from the library >>>>>>> Revision What should you want to judge that the code should be, make the necessary modifications, delete the CVS tag, and submit your modification to the library. 6, submit your modification to CVS From the server Checkout project, the copy of the file will be created locally. After the client modifies (commit) to the server, you can save the latest file to the server, and the modified file is displayed in red. Place local modifications to the library, called submission modifications. 1) Before submit, you should do an update to make sure there is no conflict. See the modification of others from CVS 2) Select the directory or file you want to submit 3) Click the right mouse button on the selection, select Commit Selection from the menu. 4) In the CommTings Submit Settings dialog, enter log information. This step is optional, but it is highly recommended that you take a short to describe your changes. 5) Click the OK button. The file version will be automatically added. Note that submission modifications do not automatically add new files you created to the library. See adding files and directories. 7, check the modification WinCVS can view status, logs, differences, and so on for files and directories. 1) Select the directory or file you want to view. 2) Right-click on the selection, select Diff Selection, Log Selection, Status Selection (status) or Graph Selection 3) If you pop up the dialog, enter the necessary information, then click the OK button. DIFF Selection: Compare any revision of the corresponding document in the local copy and the library. It is also possible to compare different revisions in the library. The output is a row at the beginning of "<" or ">", indicating the revision and another comparison deletion or increase. Log Selection: Display all revisions of the specified file (unless you qualify the registered version of the revision to display), the date, tag, author, etc. STATUS Selection: Displays the modified state of the specified file, such as the file is local modification or the library is modified. If possible, the revision number in the local and library is also displayed. Graph Selection: The graphic displays a revision of a given file that is especially useful when the file has one or more revision branches. The local revision is marked as a document icon. Take this, you can choose two revisions to compare (using Shift keys). 8. Tag tag on the file In a specified phase developed, a tag tag for one or more files is called a reference to these file tags. The label is used for the entire module to be re-constructed for future modules. This label is always performed when the project is issued or started, and the following steps are performed on one or more files or directories. 1) Select the directory or file you want to mark the tag 2) Select MODIFY-> CREATE A TAG ON SELECTION 3) Input tag inside the New Tag Name New Tagname Input box (see the restrictions on the standard registration below) 4) Click the OK button. Note: CVS is very strict on the characters contained in the tag. A label must begin with letters, follow-up multiple letters, numbers, minusks and underscores. It is specifically pointed out that there is no order, nor a space. If you want to include the version number in the label, please change the point to the minus. Two labels are preserved as unique meanings in CVS, "head" refers to the latest version of the library, and "Base" means that you finally check out the local revision. 9, increase files and directories When you create a file you want to put in the library, you have to tell CVS to do appropriate processing. If the directory contains files that are not in CVS control, you need to add files or directories, you want: 1) Select the directory or file you want to add 2) Select MODIFY-> Add Selection or Add Binary or Add Unicode menu. For non-text files, choose binary, and free file will be broken by CVS. 3) The file is only marked as added, you have to add it to the library by submission. If you don't know how to submit, see your changes to CVS. If you want to add a directory layer, not a few files, the above technology is a bit trouble, because the addition operation does not support subdirectories. In this case, you have to use the input, just like create a new module, see check. 10, delete files and directories To delete a file, you first have to determine the delete, then submit your changes. 1) Select the file you want to delete 2) Select MODIFY-> Remove menu 3) The file is only marked as delete, you will also remove it from the library by submitting. If you don't know how to submit, see your changes to CVS. Note that the file is not physically deleted, just being marked as "dying". In this way, if you choose the old revision of the module, you may still recover the deleted file. The delete directory is another topic. When you update a parent directory of a directory, CVS deletes empty directories. If you want to delete an empty directory, the operation is as follows: 1) Select the parent directory of the empty directory you want to delete 2) Click the right mouse button to select the Update Selection Update menu 3) Select the globals box 4) Determine that prune Empty Directories is selected (this is a default) 5) Click the OK button. If the files in a directory have previously been removed from the local and libraries, this empty directory will be deleted. 11, retrieve the deleted file If you just click the Delete button to delete the file, click the Add button to retrieve the file. If you have been submitted to the server, delete the file from the server, you should establish a file with the same name locally (can be empty file), add the file to the server, at this time, you can find the lost file, just Upgrade a version of the local created file on the basis of the deleted version. The historical version of the file still exists. If you want to overwrite the current version, the easiest way is to merge (MERGE). 12. Move or change your name for files and directories Operations for files and directory movements or modifications are not allowed in CVS. This is a shortcomings of CVS. You need to merge delete and add operation to simulate movement or rename. See adding files and directories and deleting files and directories. 13, branch One feature of the version control system is to isolate the modification to a separate development line. This line is called a branch, creates a branch by the following steps: 1) Select the directory or file you want to branch. 2) Select MODIFY-> CREATE A BRANCH 3) In the New Branch Name New Branch Name Inframe, enter the tag name of your request. 4) Select Check That The Files Are Unmodified Before Branching 5) Click the OK button. Now in the library creates a new branch according to the specified name, the branch is only created in the library. To work on the newly created branch, you have to do some work according to the description of the selection of a branch. 14, choose a branch work To work on a branch instead of the default development line, you have to receive your local copy to the branch. This requires some confidential operations such as updates, submission, and the like on the branch instead of the main line developed. Transfer your local copy to another branch, the operation is as follows: 1) Select the top-level directory of the project (if you know the directory and files within the branch, you can also choose) 2) Right-click on the selection, select the Update Selection Update menu 3) Confident Create Missing Directories That Exist in the repository is selected. 4) In the Update Options page, select Retrieve Rev./tag/branch 5) In the Retrieve Rev./tag/branch input box, enter the branch tag name you want to switch to 6) Click the OK button WinCVS will update the updates to update your work and transfer to the expected branch. The update operation will increase or delete files. CVS marked the branched file with a bonded label. You can view these sticky labels by performing status commands on files. See reviewing modifications. To delete a sticky label, return to the development main line, perform the steps that returns the development main line section. 15, merge from the branch When the Update file, the third Tab is the merge option. That is, the merged file is performed by Update. As described below, there are several merged methods. As shown above, the V_DS version is overridden in another v_xj. As shown above, the V_DS version is compared to the current version. Mer consolidation with the current version of Only this Reg./tag, usually there is a conflict. E.g v_xj is the current version, the file content is: --XJ xj The content of the V_DS file is: DS Before Merge -DS Now it become the file of ds I want to merge agagin Set the merge version above, display the file conflict, open the files as follows: <<<<<<< Test.txt --XJ xj ======= DS Before Merge -DS Now it become the file of dsi want to merge agagin >>>>>>> 1.1.4.4 Remove the collision identifier added by the CVS, modify the file as the desired look, COMMIT. When you are very satisfied with your changes you on your branch, you may want to develop the main line and get these modifications. Merge a modification on a branch to another branch called a merge. To merge a branch, to execute: 1) Move the local copy to the branch you want to modify. See Select a branch to work or return to the main line 2) Select the top-level directory of the project (if you accurately know the directory and files within the branch, you can also choose) 3) Click the right mouse button on the selection, select the Update Selection Update menu 4) Confident Create Missing Directories That Exist in the repository is selected. 5) Select Merge Options page 6) Select Only this Rev./tag 7) In the ONLY THIS Rev./Tag input box, enter the branch tag name you want to merge. 8) Click the OK button. Any changes on this branch will be merged into your local copy. You may also want to submit the merged files in the back library, see Submitting your changes to CVS. 16, return to the development main line If you want to stop the work on your branch, turn the local copy back to the development main line, you have to delete all stick tags via WinCVS. To delete the sticky label update local copy, return to the development main line, etc., perform the following: 1) Select the top directory of the project (if you know the directory and files in the branch, you can also choose) 2) Right-click on the selection, select the Update Selection Update menu 3) Confident Create Missing Directories That Exist in the repository is selected. 4) Select RESET Any Sticky Date / Tag / '- K' Options 5) Click the OK button. WinCVS will update your local copy to make the current development main line. The branch that once worked still exists in the library. Whenever you can return to this branch, see Select a branch. 17, who is editing the file Query CVS Who is editing a file is ok, but only developers notify CVS. They are going to edit a file. This approach is called IR CVS mode, and if you want to use this method, you should decide well at the beginning of the project. To use IR CVS, developers should detect modules in read-only mode. You can choose Checkout Read-Only to do this in the gloAbals box of each WinCVS dialog. To edit a file, do the following steps 1) Select the file you want to edit 2) Select the Trace-> Edit Selection menu, read-only tags will be deleted, and the CVS server will register you is the editor of the specified file. 3) Edit file 4) Submit a file in accordance with the instructions submitted to CVS. When you submit a file, the CVS server assumes that you no longer edit it, WinCVS tagged the file as read-only. If you don't make any modifications, the submission will not notify the CVS server you have completed editing. In this case, you have to do the following: 1) Select the file you marked as editing 2) Select the Trace-> Unedit menu, Now, return to the original question: "Who is editing the file." To list a file editor, execute: 1) Select the file you follow 2) Select the Trace-> Editors menu, WinCVS will list editors of the file. Fourth, TortoiseCVS Basic Operation TortoiseCVS is a concise and effective CVS interface that provides the "Point-Click" operating environment that can be used to replace WinCVS to do everyday work, download web page: http: // TortoiseCVS. SourceForge.Net/download.shtml. Note: It is only the most basic CVS app introduced below. TortoiseCVS is not a fully functional CVS GUI. If you need further help, follow its latest stable versions and refer to its help. 1, Checkout In TortoiseCVS, a copy of the source code from Checkout on the CVS server is called Sandbox on a local machine. Select a local catalog, right click, select CVS Checkout in the pop-up menu ... Protocol: Fill in the name of the protocol connection to the remote CVS warehouse; Server remote CVS warehouse name or IP address; Port remote CVS warehouse used by the port, generally does not require; Repository Directory: The absolute address of the remote CVS warehouse in the server User name: User account using remote CVS warehouse; CVSROOT: CVS environment variable, this option will automatically generate, and the specific meaning is shown in the CVS environment setting. Module You need to check the module name, which is case sensitive. The icon of the file is as follows: 2, Update Select the file or directory you need to add, right click, select CVS-> Update in the pop-up menu, display the following picture: 3, commit Select the file or directory you need to add, right click, select CVS-> Commit in the pop-up menu, display the following picture: 4, add Select the file or directory you need to add, right click, select CVS -> Add in the pop-up menu, display the following picture: You don't need to worry about the type of file, such as ASCII / text, Unicode / Text, or Binary, TortoiseCVS automatically recognizes them. 5, Create new module / repository If you can connect the remote server, there is no remote CVS warehouse, then the following prompt box appears: Create a new CVS warehouse, hook the Initialise A New Repository Here check box, as long as you have the right permissions on the remote server, you can create a new CVS warehouse. 6, Tag / Label Select the file or directory of the label, the mouse right click, the pop-up menu appears, select CVS_TAG, appears as shown below: V. Version control via CVS 1, revisions and release concepts The first meaning of this document is "revisions", and its second meaning is "Releases". For most CVS users, they do not need to consider the revision number when submitting (CVS commit), as long as the CVS has automatically added amendment number similar to 1.1, 1.2. If the user wants to track a series of version numbers of many files, such as a special release version, he uses a special label (tag) as a revision number, the function of this symbol tag and the value of the numerical revision number of each file are the same of. Each file has a unique "Revision Number", the form of revisions is usually true: 1.1, 1.2, 1.3.2.2 or even 1.3.2.2.4.5. A revision number always has a decimal number of dollars divided by an even number of sentences. The default revision number of a file is 1.1. The rightmost number of each new revision number will be more than the top right of its last revision number. If the revision number contains more than one period, such as 1.3.2.2. This revision number indicates that the revision is on the branch. A file can have several versions (Version), just as described above. Similarly, a software product can also have several versions. Generally a software product has a version number, such as 4.1.1.2, label Sometimes we need to obtain source code for the entire project based on a specific event or a certain condition. If the version of the project is released, some important features are released, or the version of the version is released, or the version is added or deleted. However, the version number of each of the different files in the same project is very large, and the CVS version number mechanism is largely automatically, and we are difficult to control it, so CVS provides a "label system", it can Help us get snapshots of a specific phase code tree (ie, the file at the time), or add "tab" for a snapshot, return to the specified snapshot by reference label. The label is a symbol that is paid to a file or a set of files. In the life cycle of the source code, the file that makes up a set of modules is assigned to the same label. The version tag provides a chain that is connected to different versions of different files we want. In the Status Command Status you can use the -v option (see Status Command) to view all the tags of the representative version number of the file. I rarely add a label for a single file. A more common usage is to add tags to all files of a module after each milestone task in the product development cycle, such as tags of various baseline versions, including various test versions, publishing versions. 2.1 Creating a label (TAG) Perform CVS Tag in the working directory: $ CVS Tag Rel-0-4 Backend.c T Backend.c This will separate a branch based on the file backend.c in the current working directory, and assign the REL-0-4 name to the branch. The label name must begin with letters, and the middle can contain letters, numbers, underscores, and even characters. During the entire software development process, the name of the label is specified. $ cvs status -v backend.c ============================================================================================================================================================================================================= ================== File: Backend.c Status: up-to-Date Version: 1.4 Tue Dec 1 14:39:01 1992 RCS Version: 1.4 /u/cvsroot/yoyodyne/tc/backend.c ,v Sticky Tag: (NONE) Sticky Date: (NONE) Sticky Options: (NONE) EXInship tags: Rel-0-4 (Revision: 1.4) Normally, a version tag is specified for a single file, usually specify a label for a baseline version, that is, for all code, documentation, and data from the software configuration, need to be uniformly attached to a version tag. The baseline version is a single source code, documentation, and some versions of the data file in a software project, and each file is only a version or one version is not taken. The baseline version is set and the software process definition has a close relationship. The label is not attached to our work copy, but is on the latest version in the warehouse of CVS. This leads to a problem, it is possible that we have not submitted a label yet, and the label is not put on the release of the label on our hopes, to prevent this method: $ cvs tag -c baseline_1 CVS TAG: TEST.C is LOCALLY MODIFIED CVS [Tag Aborted]: CORRECTG The Above Errors First! Discover this error, you can refer to the mobile label. Use CVS RTAG -D DATE TAG Modules to label according to time. $ cvs RTAG -D 20011010 Nightly_20011010 TEST Put all the files of the TEST module on the last version of the Nightly_20011010 tag before 0:0 on October 10, 2001. You can also follow the version number or already label label, format: cvs RTAG -R Revision / Tag Tag Modules ... $ cvs RTAG -R nightly_20011010 REL_2_1_0 TEST If a label is the version of the Nightly_20011010 has passed all reviews and tests, you can use the above command to put the tag version of the label Rel_2_1_0. Option -f is used to force the label in both cases to attract the latest version when you find any matches. This option prevents certain files from missing to the entire software configuration. 2.2 detection of version label Use the -R option in the checkout command to check out all the files of a version of a module. The following command can easily detect all source files of the module TC version 1.0.4. $ cvs checkout -r Rel-0-4 TC If we remember the label on the initial code tree, it is "Base", and now you want to start starting from the original source tree, we can use the following command to check out the "Base" version of the code: $ cvs checkout -r base community Or, if our currently written code belongs to version 3.8, then you can use the following command to add the label: $ cvs tag release-38 CVS TAG: tagging. T functions.php3 T index.php3 T post.php3 T tPHP3 T search.php3 In the future, when we want to get "Release-38" file, simply do the following command: $ cvs checkout -r release-38 Community CVS Checkout: Updating Community U community / functions.php3 U community / index.php3 U community / post.php3 U community / read.php3 U community / search.php3 U community / sql.php3 Also, we can also use the "CVS Update" command to jump existing version to another version corresponding to the version number: $ cvs update -r release-38 Community Specific versions can also be obtained according to time: $ CVS Update -D "2001-05-08" The -d option allows CVS to find the latest version of each file of 06 06 May 2001 to remove these versions from the warehouse. 2.3 Adhesive Tags (Sticky Tags) Some versions numbers include other attribute data, which is mainly used in: 1) Version branch: Version branch label is associated with version branches when creating branches, and it is always valid before release. 2) Keep a few files do not change: Sometimes you may need to keep a few files, you can use the cvs update -r, command to create a attachment tag for the file, and execute the cvs update command in this directory, which The file will not be modified. Similarly, if the developer wants to detect the version at a date point in time, and when you don't want to execute CVS Update, these files are updated, you can use CVS Checkout -D or CVS Update -d to reach This date is associated with this version. For this old version of the modification and submission of the formation, the following methods can be used: 1) Treatment, process method, see the method of rewinding the version. 2) Export code and process all files at a time. Firstly, the attachment label will be canceled using $ cvs update -a to cancel all adhesion tags, version numbers, and then export code in a temporary directory: $ cvs export -d "2001-05-08" TEST; finally all code Copy to the original directory to overwrite all the original file $ cp -r. The use of CVS EXPORT is shown in the release source (export). 3) Use the "-j" option to update the command, see the method of retreating from the version. 2.4 Delete Label Tags usually do not modify the label. Their existence is to update history for record source code libraries. If deleted or modified itself is a violation of the original intention. If you use a temporary label, or misunderstand the label, you can also delete, move, and rename an operation. To delete the label, add -d option after CVS TAG or CVS RTAG. $ cvs tag -d baseline_1 Rename the label $ cvs tag -r Baseline_1 baseline_2 $ cvs tag -d baseline_1 Remove non-branch tab REL-0-4 from the module Tc: $ CVS RTAG -D REL-0-4 TC 2.5 mobile label Moving a label is to assign this name to another version. For example, the Stable tag is now used on version 1.4 of file backend.c, we want to transfer it to version 1.6. Add -f options after the CVS Tag or CVS RTAG command. We can do this: $ cvs tag -r 1.6 -f strable backend.c 2.6 Rename the label Rename a label, telling a version of the already label name on a version. For example, someone will write the label name and to correct it (I hope other people have not used this wrong tag). To change the tag name, first with the CVS RTAG command with the -R option, then delete the old label name (note: This method is invalid for the branch label). The label position after the name is the same as the original label. E.g: $ cvs rtag -r old-name-0-4 rel-0-4 tc $ CVS RTAG -D Old-Name-0-4 TC WARNING: Delete, move, and rename label operations are risky, they will permanently erase historical record information and can not recover once the error is wrong. 3, branch Version branches are a secondary version sequence that the user exported on a major version sequence. The branch version is coexisting with the main version sequence, and parallel development can be done. If necessary, the branch version can be merged to the main version. Version branch is one of the most important features of CVS, and is also one of the most easily used characteristics. Developing some functions that are not very grasped and destroying the entire project can be developed on a branch to play a huge role, but if management is not good, it will lead to a major confusion. CVS branches can be used in parallel development, multi-platform (customer) parallel development, multi-platform (customer) parallel development, multi-platform (customer) parallel development, Nightly Build. The CVS branch is mainly used to modify the history of the working copy, and the previous version of information is disabled without branch. It is recommended to establish a branch every release. Strictly follow the principle when using the branch: u minimize the number of active branches, to reduce the possibility of conflicts at the time of consolidation, and the multi-version consolidation is frequently u minimize the level of branch; u Use a unified and meaningful label to name a branch; u Specifies the creation and management of the dedicated version branch. 3.1 Creating a version branch (tag -b) There are two ways to create version branches: Create and create directly after the release. When the version is just created, all the code of the branch version is exactly the same as this branch based version (becoming branching point). After the branch is created, the branch label is associated with the head version of the branch tree, not associated with the branch base point. If you need to access a branch base point in the future, you need to give the main code tree when you create a branch. You can use the tag -b command to assign a version of the symbolized name to some versions of the file, modify some files without affecting the main, when commits. CVS allows you to modify the code to different development lines, which is branch. When you change the files in a branch, these changes will not appear in main development backbone and other branches. Check out a version of the code from the work copy, then create a branch, use tag -b, for example: $ cvs checkout -r baseline_1 test $ cvs tag -b Baseline_1_path test This will separate a branch based on the current working directory and assign the Baseline_1_path name to the branch. Use the RTAG command to create a branch directly in the warehouse: $ cvs RTAG -B -R Baseline_1 Baseline_1_path_2 TEST -r Baseline_1 Description This branch is based on files with the Baseline_1 tag, which is useful for separating a branch from the old version (for example, a release of the previous version that is considered a stable release). 3.2 Access branch You can enter the branch in two ways: re-check one or switch from existing working copy. Re-detection uses the checkout command and bring the -R ID, followed by the name of this branch (TAG) name. Such as: $ MKDIR WORK $ CD WORK $ cvs checkout -r Rel-1-0-Patches TC Or if you already have a copy, you can use the update -r command to this branch: $ cvs update -r Rel-1-0-patches TC One, your work copy has turned to a specific branch. It will remain in this branch unless you do other operations. 3.3 Determine on that branch $ cvs status -v backend.c ============================================================================================================================================================================================================= ================= File: Backend.c status: up-to-Date Version: 1.4 Tue Dec 1 14:39:01 1992 RCS Version: 1.4 /u/cvsroot/yoyodyne/tc/backend.c ,v Sticky Tag: (Baseline_1_path (Branch: 1.1.2) Sticky Date: (NONE) Sticky Options: (NONE) 3.4 Merge of version branch The merger of the version is to merge different versions of the code so that the merged versions include all works on different versions. Use the CVS Update -j command to merge these changes to the working directory. Then you can submit this version. $ CVS Update -j Rel-1-0 Print.c Every time you merge the changes in the branch version to the backbone, all modifications between the branch base to the branch are all incorporated onto the backbone. Conflicts may occur when merging, if this happens, you can resolve it before submitting new versions, see processing conflicts on conflicts. Use two-J Revision flags, Update (and Checkout) commands to merge two different versions of differences to your work directory. $ cvs update -j 1.5 -j 1.3 backend.c A tip of repeated merger is the label of the branch version of the tree after each merger. This allows the branch versions of each merge to identify the label, which can only be merged. Note: You must express the meaning of you want to merge only the content that is not merged. This requires two "-j" parameters. CVS combines from the first "-j" version to the second "-j" version of the "-j" version. Otherwise, CVS may try to merge something you have merged, which may write something that does not want to happen. 3.5 Clear a bug in the release of the publishing, a whole process of branch, merge 1. Check out the latest version and the last release version in the working directory $ CVS Checkout Test $ cvs checkout -d test_old -r rel_2001_10_10 Test Save the last discovery version in the Test_old directory. 2. Create a Bugfix branch $ CD Test_old $ CVS TAG -B REL_2001_10_10-Bugfix 3, go to the branch version $ cvs update -r rel_2001_10_10-bugfix 4. Modify files in branch versions, such as Test.c 5, submit a Bugfix branch version $ cvs commit -m "fixed bug no.12345" TEST.C 6. Go back to the directory where the backward version is located, merge the branch version to the latest home version $ cd ../test $ CVS Update -J Rel_2001_10_10-Bugfix Test.c 7. Finally, submit the merged results to form a new version of the merger $ cvs commit -m "merge from branch rel_2001_10_10-bugfix" test.c4, release source (Export) For developers, if you need to get the source code of the software, the detection mechanism using CVS is already enough. However, for ordinary users, they don't have to learn to use CVS, then detect all source code, they need more simple ways to directly obtain packaged software source code. CVS uses CVS Export for developers to output source code into the directory. Different, CVS EXPORT takes out is a source code directory tree without CVS traces. $ cvs export -r rel-1_0_0 -d Test-1.0.1 Test The -d option saves the output file as a subdirectory of TEST-1.0.1. Six, basic flow charts of CVS operations 7. Advanced operation of CVS 1, define the CVS module The CVS module is a very important concept in CVS, which is a CVS project organization. The concept of the CVS module is greatly facilitated project management. Typically, the directory in the module and the CVS warehouse corresponds to. The project manager can organize the submodules of the project similar to the tree structure similar to the directory structure and then combine the child module into a module. Basic module definition: The module name directory name // directory name relative to the warehouse path. Select the file composition module: Module Name Directory Name File Name List // Defining Module consists of files in this directory, directory name // For the warehouse path. Exclude directory: Module name! Directory name list // When checking out the module, exclude the directory listed in the directory name list Aggregate multiple directory: Module Name -A Directory list // below multiple repository directories under a module, but still in each // self-directories. Module alias: Module Name & Module Name // CVS Allows to point to other modules Define the method of the CVS module: 1) Test the modules profile from the CVS warehouse 2) Add the module definition in the module file detected. 3), submit the module definition to CVS warehouse After success, CVS will prompt: Rebuilding Administrative File Database. Without this information, it indicates that the submission failed. If you do not define the CVS module, you can also check out the code, the premise we know the location of these directories and files in the CVS warehouse. Let developers to remember that the location of each directory in the CVS warehouse is clearly not a good way. In a regular development process, or to follow the way the module is defined. 2, CVS and binary files So far, we mainly operate the text type file, and CVS will manage some special processing when the text file is managed, allowing us to use it more convenient. Such as the process of entering the loan. In addition, CVS also do other processing work in text files, extending some strings including certain keywords. But these modifications will destroy non-text types such as binary files, control, .dll files, .doc files, and these files also need to be managed. CVs can be prohibited from being replaced and expanded by modifying the CVS profile. But there is no way to make a version comparison of non-text type files. Therefore, the Word document must be done using the revision function of Word software. 1, configure the cvswrappers file $ cvs checkout cvsroot / cvswrappers In the end of the file, add the following value (depending on the specific file): * .gif -k 'b' * .Gif -k 'b' * .jpg -k 'b' * .Jpg -k 'b' * .png -k 'b' * .Png -k 'b' *. Pdf -k 'b' * .Pdf -k 'b' * .avi -k 'b' * .Avi -k 'b' * .mp3 -k 'b' * .Mp3 -k 'b' * .mpg -k 'b' * .Mpg -k 'b' * .doc -k 'b' * .Doc -k 'b' * .xls -k 'b' * .Xls -k 'b' * .xl * -k 'b' * .Xl * -k 'b' * .MPP -K 'B' * .MPP -K 'B' * .ppt -k 'b' * .Ppt -k 'b' * .dot -k 'b' * .Dot -k 'b' * .jar -k 'b' * .Jar -k 'b' * .tif -k 'b' * .Tif -k 'b' * .swf -k 'b' * .Swf -k 'b' * .bmp -k 'b' * .Bmp -k 'b' * .exe -k 'b' * .Exe -k 'b' * .o -k 'b' * .O -k 'b' * .tgz -k 'b' * .Tgz -k 'b' * .gz -k 'b' * .Gz -k 'b' ...... $ cvs commit cvsroot / cvswrappers 2, interaction between CVS and Build system A problem is how to get the latest copy of the source code. First, use the cvs -q update command, use other commands in the Make or Build tool. Second, before completing your task, you don't have to consider the changes you made by others. The proposal is to update source code, modification, build, and test your changes, then submit (if you need to update) your source code. Update your source tree by periodically (modifications, such as just described), you can make sure your source code is new enough. There is also a common need to record the version of the source code in Build. The best solution in CVS is to use the tag command to record the version of the special build. Most simple use of CVS ways, each developer will have a copy of the entire source tree for a specific build. This is a relatively appropriate way if the source tree is smaller or the developer's geographic location is a relatively appropriate. For large projects, it should be divided into small subsystems that can be independently compiler, which can be released inside so that developers only need to detect their own corresponding subsystems. Another way is to create a structure that developers have their own copy, and other files are obtained from the center. A symbolic link can be used on many systems, or using the VPath feature of Make. 3, how to restore the file that has been deleted The test steps are as follows: 1. Create a new file TEST 2. Add new file CVS Add Test 3. Check in: CVS CI Test (Generate 1.1 Version) 4. Delete the file in the working directory: RM Test 5. Delete files in the CVS warehouse: CVS RM Test 6. Check in: CVS CI Test (Generate 1.2 version DEAD) The following is a recovery process: 7. Create a file test 8. Add file CVS Add Test (note the result on the screen) 9. Check: CVS CI Test (Generate version 1.3) The following is more interesting: 10. Restore the file content: CVS UP -J 1 -J 1.1 Test 11. Check in: CVS CI Test (Generate 1.4 version) To this Test file recovery. 4, version rollback If there is a project group member submitted a wrong version, everyone, of course, the wrong version is currently the current version. A simple and convenient solution is to return the version back to the nearest version. CVS does not allow users to truly delete any of its saved versions. So we can't remove the submitted error versions from the CVS warehouse, let the previous version become the latest version. If you use cvs update -r1.2 file.name This command is given to file.name plus a Stick Tag: "1.2", although your original intention just wants to return it to version 1.2, if you accidentally add Stick Tag: Solve with CVS Update -a. There are two ways to solve this problem here: Method 1: First update to the latest version, and then remove the old version to re-submit. The first step is updated to the latest. Because before commit, you must update to the latest version, otherwise it will be mistaken. $ CVS Update CVS Server: Updating. P test.c CVS Server: Updating Newdir In the second step, remove the old version in the CVS warehouse, pay attention, you cannot use "CVS Update -R 1.2 Test.c" to complete this (see the attachment tag). Below this command uses a "-p" option, this option allows CVS to do not really perform the task of updating the copy of the copy of the copy, but output the source file removed from the CVS warehouse to the screen (standard output device). In order to be able to directly output the source code file, use the "q" option to make CVS block information. Write these outputs to the file with a redirect operator ">". The following command enables the output content to the test.c file. $ cvs -q update -p -r 1.2 Test.c> Test.c Then we submit the Test.c file to form a new version. $ CVS CI -M "Reverted to Revision 1.2" TEST.C CHECKING in Test.c; /src/master/test/test.c ,v <- test.c New Revision: 1.4; Previous Revision: 1.3 DONE Let's take a look at the 1.2 version and version 1.4 version is exactly the same. $ CVS DIFF -R 1.2 -R 1.4 Test.c INDEX: TEST.C ========== RCS file: /src/master/test/test.c ,v Retrieving Revision 1.2 Retrieving Revision 1.4 DIFF -R1.2 -R1.4 The results show that the two versions are exactly the same, the task is completed correctly. Method 2: Update command with -J This command can use two "-j" options, and the parameters behind this option are the version number. When using two "-j" options, this command hits the difference between the two versions as patch (patches) on the current file. Therefore, the order of the version numbers behind the two "-j" options cannot be mistaken. It is equivalent to continuous "DIFF" and "patches" two commands. $ cvs update -j 1.3 -j 1.2 Test.c RCS file: /src/master/test/test.c ,v Retrieving Revision 1.3 Retrieving Revision 1.2 Merging Differences Between 1.3 and 1.2 INTO TEST.C The above commands replenish the difference between the 1.3 version and 1.2 version to the current version 1.3, so it is equivalent to subtracting changes between 1.2 to 1.3 from version 1.3. The following command displays the status of the file: $ cvs status test.c FILE: Test.c Status: Locally Modified Working Revision: 1.3 Repository revision: 1.3 /src/master/test/test.c ,v Sticky Tag: (NONE) Sticky Date: (NONE) Sticky Options: (NONE) Submit to form a 1.4 version. $ CVS CI -M "Reverted to Revision 1.2" TEST.C CHECKING in Test.c; /src/master/test/test.c ,v <- test.c New Revision: 1.4; Previous Revision: 1.3 DONE View the difference between its contents and 1.2 versions: $ cvs diff -r 1.2 Test.c $ Sure enough, the file has been identical to version 1.2. The task is successfully completed. If you want to fall back to multiple files, you will use the second method faster. It is important to emphasize that if the mutual understanding between the members of the development team is insufficient, a large number of version retrans is a very dangerous signal. This shows that the current situation of this team is very poor, and communication between the developing team members is not CVS to be replaced. 5, merge and keyword If your merged files contains keywords, you will usually get countless conflict reports at the merge, because it is very different in different versions. Therefore, it is often necessary to use the "-kk" selection when merged to use the keyword name, not the method of expanding the value of the keyword, this feature selects the same version to ensure that the merged version is the same, but avoids conflict . For example: Suppose you have a file as follows: And your current work directory copy is the main (1.2 version). Then, the following merge will produce a result of conflict. Please see example: $ Cat File1 Key $ Revision: 1.3 $ ... $ CVS Update -J BR1 U file1 RCS file: / cvsroot / first-dir / file1, v Retrieving Revision 1.1 Retrieving Revision 1.1.2.1 Meging Differences Between 1.1 and 1.1.2.1 Into file1 Rscmerge: Warning: conflicits during merge $ Cat File1 $ <<<<<< File1 KEY $ Revision: 1.3 $ ======= Key $ RERISION: 1.1.2.1 $ $ >>>>>>> 1.1.2.1 ... The conflict occurs when trying to merge 1.1 and 1.1.2.1 into your working directory. Therefore, when this keyword comes from "Revision: 1.1" to "Revision: 1.1.2.1", CVS will try to merge this change to your work directory, this is conflict with the change in your directory "Revision: 1.2" . The following is used: "- kk" example: $ Cat File1 Key $ Revision: 1.3 $ ... $ CVS Update -kk -j BR1 V file1 RCS file: / cvsroot / first-dir / file1, v Retrieving Revision 1.1 Retrieving Revision 1.1.2.1 Merging Difference Between 1.1 and 1.1.2.1 Into file1 $ Cat File1 Key $ Revision: 1.3 $ ... Both "1.1" and "1.1.2.1" here are expanded to pure "revision", so there is no conflict when merging. However, using the "-kk" parameter is also a major problem. That is, it uses the keyword extension mode commonly used by CVS. In special cases, if the mode uses the "-kb" parameter for binary files. This will have a problem. Therefore, if you include binary files in your database, you will have to handle these questions without using "-kk". 6, backup and movement of CVS warehouse When the CVS backup, the CVS server cannot be in the state of accepting the user command, that is, you can't do anything. There are two ways to do this: 1. Prohibit any users from using CVS for a while to ensure that all previously submitted CVS commands have been executed; 2. Automatically prohibit all users from using CVS to locate the CVS warehouse by creating a # cvs.rfl file in each repository, or using CVSLock to lock the entire CVS warehouse. The CVS warehouse moves like a CVS backup, you need to ensure that no CVS operations can begin before. Pack all the files and catalogs under $ cvsroot, compressed with Gzip, and ftp to the target computer or directory. Eight, CVS restrictions CVS is not a Build system. The CVS does not include the function of making the source code build into software. CVS cannot guide you how to construct something, it just saves your design in a tree structure for recovery. CVS cannot determine how to use disk space in a check-out directory. If you write your Makefiles or script in each directory, you must know all the relative positions of others, sometimes you have to check out the entire source code library. See the interaction of CVS and Build system. CVS cannot be replaced by management. CVS is just a tool used to make your resource consistent with your step. Project team members should communicate frequently to ensure time meter, consolidation points, branch names, and release dates. If you don't do this, CVS is useless. CVS cannot replace the communication between developers. When changes in a file or multiple files, CVS does not know when they are logically conflicted. Its conflict concept is pure textual. CVS does not point out a logical non-text or distributed conflict. For example: If you change the parameters of the function X in file A. At the same time, others are editing the file B, still calling X this function with the old parameter. Conflict CVS at this time can be effortless. CVS has no change in control. Change control can refer to many things. First it means that it can be bug tracking, that is, it maintains a database, including the reported bug and each bug state (such as: Is it correct? Which one is it? Submit this bug Does people think it is already correct?). In order to coordinate CVS and an external tracking BUG system, please refer to RCSINFO and VERIFYMSG. Another aspect of changing control refers to the situation that is like a case, that is, the change in several files is actually only the same logic. If you change a few files in a CVS Commit operation, CVS will forget that they are changing together, even if they share a log information. In some systems, another aspect of change control is the ability to track the state of each change. Some changes are written by a developer, while others make comments by another developer, and so on. In general, use CVS to create a DIFF (with CVS DIFF or DIFF), you can use patches. This is very flexible, but relying on the mechanism other than CVS to ensure that things will not collapse. CVS has no built-in processing model. Some systems provide some ways to ensure that the change or release of different steps, as well as various required approval processes. In general, you can use CVS to complete it, but it is not too enough. In some cases you want to use the commitinfo, loginfo, rcsinfo or verifymsg files, requiring certain operations before CVS commit. CVS is just a system of management code versions. CVS can't help us improve the quality of the code, can't help us understand the structure and system of the code, and improve software stability has also completely exceeded CVS's responsibilities. appendix reference: 1, CVS and Nightly Build Technology Yang Jinfang Tsinghua University Press
