CVS client
Summary
CVS is a client / server system that allows developers to store their items in a central location called repository. Using CVS client tools, developers can make changes to the content of the repository. The CVS repository will record each change made to each file, and create a complete project development. Developers can request the old version of a specific source file, view the change log, and perform other useful tasks as needed. (2002-09-02 13:01:24)
By Wing, Source:
Ideal
What is CVS? CVS is a client / server system that allows developers to store their items in a central location called repository. Using CVS client tools, developers can make changes to the content of the repository. The CVS repository will record each change made to each file, and create a complete project development. Developers can request the old version of a specific source file, view the change log, and perform other useful tasks as needed. Many open software projects have their own CVS servers, project developers use these servers as their work source warehouse. Save the source code directory of the source repository is a history file that implements version control, and the history file is named FileName, V. The historical file contains enough information to restore all version files, all submitted information, and submitter information. Historical documents are often referred to as RCS files, because the RCS program is used to save all modifications of files in this format, which can get historical files from Man RCSfile. Developers will improve the source code in the CVS repository every day, and they tend to be distributed around the world, while CVS provides a necessary mechanism that combines their projects into a concentrated, collaborative whole. CVS creates an "organized adhesive" that allows these developers to improve the code without interfere with others, losing important data or omissions of important updates to specific source files. When the developer is ready, they package the current work of the CVS into a .tar.gz file, as a new official version of the package to post it. However, due to various reasons, the latest official release is sometimes not the latest. The first part of this tutorial will first describe how to use CVS to use the source code for the latest and highest developer version. Before CVSROOT, you need to know the basics of some CVS. First, in order to connect to the CVS repository, you need to know the path called "cvsroot". CVSROOT is a string, just like a URL, it tells the CVS command where the remote repository is, and how to connect it. Not only that, not only the CVS repository is local or remote, and the CVS has many different cvsroot formats in different ways to connect to it. Here are some CVSRoot examples with interpretation. Local CVSROOT
CvsRoot = / home / cvsroot
This is an example of a local CVSROOT path; if you want to connect to the local repository existing in / home / cvsroot, or have a repository installed in / home / cvsroot via NFS, you need to use CSRooot like this. Remote password server cvsroot
Cvsroot =: pserver: cvs@foo.bar.com: / home / cvsroot
Here is a cvsroot example of a remote repository, which is located on the foo.bar.com host and acts in the / home / cvsroot directory of this machine. The leader: PSERVER: "Tell our client to connect to this remote machine using the CVS password server protocol, which is built into CVS. Under normal circumstances, public CVS repository uses a password server protocol to allow anonymous users to access. Remote RSH / SSH CVSROOTCVSROOT=DROBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBINS@foo.bar.com: / data / cvs
This is an example of cvsroot using RSH or SSH protocol; in this example, the CVS server attempts to use the DRobBing account to access the repository on foo.bar.com. If the environment variable of CVS_RSH is set to "SSH", then our client will try to connect with SSH; otherwise use RSH. Users who focus on security often use SSH access methods; however, whether it is RSH or SSH method to provide an anonymous user to provide source code. In order to use this method, you must have a login account on foo.bar.com. In addition to cvsroot, you also need to know the name of the module (source code collection) to be checked, and the anonymous password to log in to the CVS password server. Unlike anonymous ftp, there is no "standard" format with anonymous password, so you need to get specific passwords from developer websites or developers. Once all of this information is known, you can start. It takes two steps to obtain the source code with the CVS interaction. First, log in to the CVS server as a remote password server. Then, use the "checkout" command to get the source code. Here is an example of a set of commands for detecting the latest Samba source code (a popular UNIX / Windows integration project):
# export cvsroot =: pserver: cvs@pserver.samba.org: / cvsroot
The first command sets the cvsroot environment variable. If this variable is not set, the following two commands will need to follow "-d: pserver: cvs@pserver.samba.org: / cvsRoot" in the "CVS" command. Set the cvsroot environment variable to some inputs.
# cvs login
(Logging in to cvs@pserver.samba.org)
CVS Password: (enter your password here)
# CVS -Z5 Checkout Samba
U Samba / Copying
U samba / manifest
U samba / readme
U samba / read-manifest-now
U samba / roadmap
U samba / whatsnew.txt
(This is just a small extract of a complete CVS Check output)
The first CVS command is let us log in to the PServer, the second command tells the CVS client to speed up the transmission speed in slow connection with Gzip compression level 5 ("-z5") to detect ("Checkout") Samba Module. For each new file created locally, CVS will print "U [Path]" indicates that this specific file has been updated on the disk. Once the command is detected, you will see the "Samba" directory in the current working directory containing the latest source code. It will also notice that there is a "CVS" directory in each subdirectory - CVS stores account information in these directories, you can ignore them safely. Once the detection ends, the user does not need to worry about whether the cvsroot environment variable is set, and there is no need to specify it on the command line, because now there is its cache in all the "CVS" directories. Remember - only set CVSROOT for the initial login and check. Updating Source Codes Now there is a source code, you can continue to compile and install them, check them, or do anything to do. Occasionally, it is also necessary to keep the source directory of the checkout with the current version on the CVS. In order to do this, you don't have to log in to PServer again; CVS will cache your authentication information into those "CVS" account catalogs. First, enter the main inspection directory (here is "samba"), then enter: # cvs update -dp
If there is any new file, CVS will output "U [Path]" when updating each line. In addition, if you have a source code, you may see a lot of "[path]"; CVS pointed out that these target files do not come from the remote repository. Also note that we are used for "CVS Update" two command line options. "-d" tells CVS to create a new directory that may have been added to the repository (By default, this will not happen), "-p" tells CVS to remove all air directories from the localized source copy. "-P" is a good choice because CVS tends to collect many empty generations generated (once used, but now have given up) directory tree. If you just have to get the latest source code, these are what you need to know. Now, let's take a look at how a developer interacts with CVS. Modifying the file as a developer, you need to modify the files on the CVS. To modify the file, you only need to make an appropriate changes to the local copy of the repository. The changes you do for the source code are not applied to the remote repository before you explicitly tell CVS "Submit" changes. All modifications are tested to make sure they can be used to use these changes to the repository normally, follow the two steps below. First, enter the following command in the main source code directory:
# CVS Update -dp
CVS Merge Other Changes We have seen in the previous, "CVS Update" will keep your source in the current version of the repository to keep your source to the latest state - but what happens to what you have done? Don't worry, they will not be discarded. If another developer makes some changes to your files, your local file will be updated to keep it synchronized with the version in the repository. If you modify the 1-10 line in the local file, another developer deletes the 40th to 50 lines, adding 12 lines of new rows at the end of the file, and modify 30-40 lines, then you before you Submitting his changes to the repository, CVS will intelligently merge these changes into your local modified copy so that your changes will not be lost. This allows two or more developers to operate at different parts of the same file. However, if two or more developers change the same part of the same file, then things are somewhat complicated. If this happens, CVS will tell you that there is a conflict. The work done will not be lost, but need to manually intervene, because CVS needs you to provide you with your opinion to decide how to merge these conflict changes. Submit us to see how the conflict is solved, but now, let us assume that there is no conflict after entering "CVS Update -DP" - there is often no conflict. The local source code is the latest because there is no conflict. You can enter the following command in the main source code directory to submit changes to the repository: # CVS Commit
The role of the submission "CVS Commit" does not only apply your changes to the repository. CVS calls the default editor before you truly submit your changes to the remote resource library, allowing you to enter the modified description. After entering an annotation, save the file, exit the editor, your changes (and annotations) will be applied to the remote repository, and other developers in the group can see these changes. View logs To view a complete history of a particular file and the annotations added to developers (including you) when submitting. To view this information, type:
# cvs log myfile.c
The "cvs log" command is recursive, so if you want to view the full log of the entire directory tree, you only need to enter the directory, enter:
# cvs log | Less
Submit options You may want to use another editor that CVS that is default when you enter "CVS Commit". If so, just put the name of the editor you want to use into the Editor environment variable. Alternatively, the update log message can be specified as the command line option, so that CVS does not need to be loaded into the editor one by one.
# cvs commit -m 'i fixed a few silly bugs in portage.py'
The .cvsrc file is recommended to set the ~ / .cvsrc file before continuing to understand other CVS commands. You can tell CVS by creating a .cvsrc file in your home directory, you can tell CVS Use the command line options you need by default, so you don't have to enter them every time. Here is a recommended default .cvsrc file:
CVS -Q
DIFF -U -B -B
Checkout -P
Update -d -p
In addition to setting a useful option for a set of CVS commands, the first line of .cvsrc puts CVS in quiet mode, its main benefit is to make "CVS Update" output more concise, more readable. In addition, once the .CVSRC is completed, "CVS Update" can be entered instead of "cvs update -dp". Adding a file to a repository To add a source file to CVS. First, create this file with your favorite text editor. Then, enter the following command: # cvs add myfile.c
CVS Server: Use 'cvs commit' to add this file permanently
This will tell CVS to add this file to the repository when you perform "CVS Commit" next time. Before that, other developers can't see it. Adding a directory to a repository to add a directory to a CVS similar to:
# MKDIR FOO
# cvs add foo
Directory / Home / cvsroot / mycode / foo address to the repository
Unlike add files, when you add a directory, it will appear in the repository immediately; do not need CVS Commit. Once you add a local directory to CVS, you note that a "CVS" directory is created in the corresponding directory of the remote CVS server, which as a container containing CVS account data. Thus, just look at whether there is a "cvs" directory, you can easily know if a directory has been added to the CVS of the remote CVS server, you must make sure it before adding the file or directory to the repository. The parent directory has been added to CVS. Otherwise, you will see the following error:
# cvs add myfile.c CVS Add: Cannot Open CVS / ENTRIES for
Reading: No Such File or Directory CVS [Add Aborted]: no repository
Familiar with "CVS Update" Before you understand how to resolve conflicts, let us be familiar with the output of the "CVS Update" command. If you create a ~ / .cvsrc file containing "CVS -Q" rows, you will find the output of "CVS Update" is quite easy to understand. "CVS Update" tells you what it is doing by printing the single character, space, and file name, what is seen; as shown in the following example:
# CVS Update -dp
Distfiles
? package
? PROFILES
"CVS Update" uses "?" characters to indicate these special files found in the ground. 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 updated the file 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] is 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 that has been successfully merged into the file. C [PATH] "C" character indicates that the file has a conflict, and it needs to be manually modified before using the "CVS Commit". How to resolve conflicts now, let's take a look at how to resolve conflicts. I have participated in most of the Gentoo Linux project, we set our own CVS server on cvs.gentoo.org. We have spent most of the time to modify the source code inside the "Gentoo-X86" module. In the Gentoo-x86 module, there is a file called "Changelog", which contains (you guess it) Our main changes to this file in the repository. An example of conflict is made by almost every developer changes the main changes to CVS, which has become the main root of conflicts - one of the conflicts here. Suppose I added the following lines at the top of Changelog: Date 25 Feb 2001
This is the thing i added myself
However, before I submitted this two new line, another developer also added these rows at the top of Changelog and submitted his changes:
Date 25 Feb 2001
This is the part address by Another Developer
Now, when I run "cvs update -dp" (you should do this before each submission), CVS can't merge his changes into my Changelog local copy, because we have added a line to the same part of the file - - How do I know which version of CVS? Therefore, CVS will appear the following error:
RCS file: / home / cvsroot / gentoo-x86 / channelelog, V
Retrieving revision 1.362
Retrieving Revision 1.363
Merging Differences Between 1.362 and 1.363 INTO CHANGELOG
RCSMERGE: WARNING: CONFLICTS DURING MERGE
CVS Server: Conflicts Found In Changelog
C changeelog
Ah - have conflicts! Fortunately, eliminating these conflicts is easy. If I start my favorite text editor, I will see the following text at the top of the Changelog file:
<<<<<<< changelog
Date 25 Feb 2001
This is the thing i added myself
=======
Date 25 Feb 2001
This is the part address by Another Developer
>>>>>>> 1.363
CVS is not one of them to discard the other, but add two versions to the Changelog file, and turn them with special separators to explicitly marks the conflict of problems. Now, I have to replace this part with a text that should appear in Changelog; in this case, the replacement text is neither my version is not his version, but the combination of both:
Date 25 Feb 2001
This is the thing i added myself
This is the part address by Another Developer
I used the appropriate text to replace the conflict part (and remained "=======", etc.), and submitted my changes to CVS smoothly. Whenever you need to edit a file to resolve conflicts, make sure you have already viewed the entire file so you know that all content; if you forget to solve a conflict, then CVS is not allowed to submit it before this conflict is resolved! Obviously, special tags that remove CVS add to conflict files are important. If you make a mistake when you resolve a conflict, then you can accidentally save your changes, then you can find your original copy in the ". # Filename.version" file. Deleting files should now learn about the last trick of CVS - remove files from the repository. Removing documents is a two-phase process. First, remove the file from the local copy of the source code, and then perform the corresponding "cvs remove" command:
# rm myoldfile.c
# CVS Remove MyoldFile.c
The file plan will be removed from the repository when you submit it next time. Once submitted, the file will be officially deleted from the current version of the repository. However, CVS does not abandon the file, but still retains the content of the file and its history, so you need it later. This is just one of the many ways of CVS protecting you valuable source code. "CVS Remove" is recursive, which means you can delete a batch of files and run from the parent directory without other arguments "CVS Remove" commands. This will mark all deleted files when submitted. If you want to remove the entire directory, I recommend using the following procedure. First, from physical deletion, "CVS Remove" deletes all files in the directory:
# rm * .c
# CVS Remove
Then perform the submission:
# cvs commit
There is a trick here. Perform the following steps to delete the directory:
# cd..
# CVS Remove MyDir
# rm -rf mydir
Note that the removal of the directory does not require another submission - add the directory to the repository and remove the directory from the resource library is real-time. A file in the revised source warehouse can have multiple versions, and the same software may have multiple versions. Generally, in the previous sense of CVS (version of the source warehouse "in the source warehouse) is generally referred to as revision (Revisions), and the version of the software is generally referred to as release. The revision number of a file is generally incremented by sequential, generally in the decimal number string of the connection, such as: `1.1 ',` 1.2', `1.3.2.2 'or even` 1.3.2.2.4.5 Label Definitions and the revision number of each file in the source warehouse is independent, there is no association relationship between each other, and there is no relationship between the software publishing number, such as the revision number of each file in a project: It may be like this: Ci.c 5.21
CO.C 5.9
Ident.c 5.3
RCS.C 5.12
RCSBase.h 5.11
RCSDIFF.C 5.10
Rcsedit.c 5.11
RCSFCMP.C 5.9
RCSGEN.C 5.10
Rcslex.c 5.11
RCSMap.c 5.2
RCSUTIL.C 5.10
To make it easy to mark, you can use a tag to set a tag for a particular version of a specific file to facilitate access, you can use CVS TAG and CVS RTAG to define the label, where the cvs tag is used for the current working file in the repository (or file collection ) Specify a symbol tag; CVS RTAG is used to explicit a file to define a file for a specific revision number of the source warehouse. For example, the following example is to define a label for the current revisions of the file backend.c, then check the status of the file:
$ CVS Tag Rel-0-4 Backend.c
T Backend.c
$ 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)
However, in practical applications, a label is rarely defined for specific files, but often defines a label for all files in the development process to facilitate publication or defining branches, such as:
$ CVS Tag Rel-1-0.
CVS TAG: tagging.
T Makefile
T Backend.c
T Driver.c
T frontend.c
T Parser.c
After defining the label, you can access item files that should be labeled at any time, such as the following command to implement all the files corresponding to the label Rel-1-0 (probably 1.0 release):
$ CVS Checkout -R Rel-1-0 TC You can imagine the curve index of the label as a specific fix number file, for example: here is the defined tag * during the software development process, or you can see the label: Of course, you can also delete the label. For example: CVS RTAG (/ tag) -d Rel-0-4 TC Delete Module TC's Rel-0-4 Tag Backup Source Warehouse Backup: Start all CVS connections, then use the CP command backup to branch through CVS You can implement a modification of the source code to a separate development line, called a branch (BRANCH). These modifications do not have an impact on the main branch and other branches when modifying the branch files. You can then make the modification of a branch to other branches. The merge is to consolidate to the current working directory (local) through CVS Update -J, and then submit a modification to affect other branches. The importance of the branch allows us to assume this situation, the version 1.0 version of the project has already been done, you will continue to develop TC projects, planning a 1.1 version within a few months, but customers complain that there is a fatal mistake in the software. So you detect 1.0 version (here is the reason for the use of tags) and discover this BUG. However, the current source code is between the 1.0 and 1.1 versions, therefore the code is in a chaotic state, and a stable version may occur within one month, so it is unlikely to get a version of the current version to be released. This is the case that you need to create a 1.0 branch containing the error modification without affecting the current development, and you can go in the main distribution of the corrected merge when appropriate. Creating a branch Creating a branch First creates a tag (TAG) for some files that intend to modify, the tag 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 Tag of. Create a label: Perform a CVS TAG in the working directory. Example: Create a label for src: CVS Checkout SRC (/ Update can also be used to update the local source code) CVS Tag Release-1-0 (for the current source code plus a label) After the label is created, you can create one Branch: CVS RTAG -B -R release-1-0 release-1-0-path print -b: Create a branch -R release-1-0: -r parameter to mark files-1 with the specified tag -0-patch: Branch Print: The module name can create branches using tag -b, for example in the working directory:
$ cvs tag -b Rel-1-0-patches
A branch will be separated based on the branch of the current work and the branch is named `Rel-1-0-Patches'. It should be understood that the branch is created in the source warehouse of the CVS, not the current working directory, and the current correction creation branch does not automatically convert the current work copy to a new branch, need to be manually implemented. You can also implement branches that do not involve the work directory by using the RTAG command:
$ CVS RTAG -B -R REL-1-0 REL-1-0-Patches TC
`-r Rel-1-0 'Indicates that the new branch created should be based on the revisions specified by tag` Rel-1-0', not based on the current job master branch. This is mainly used to create a branch from the old version (eg, the above example). RTAG -B indicates a creation branch (not just create a tag). It should be noted that the revision number of each file contained in `rel-1-0 'may be different. So the effect of this command is to create a new branch for the engineering TC - the name is `Rel-1-0-Patches ', which is based on tag` Rel-1-0'. Access branches can access branches in two ways: Reperse branch code from the source warehouse, or switch the current work copy to a branch. Creating a new branch from the source warehouse You can use the command 'checkout -r release-tag' command: $ cvs checkout -r Rel-1-0-Patches TC
Switch the current branch to the branch command:
$ cvs update -r Rel-1-0-patches TC
or
$ CD TC
$ cvs update -r Rel-1-0-Patches
Subsequent submission and the like affect the operation of the source warehouse only work on the branch without affecting the main branch and other branches. You can use the Status command to see which branch of the current work copy belongs. Output in the output of 'sticky tag' information, this is the CVS display current working copy is on which branch:
$ cvs status -v driver.c backend.c
============================================================================================================================================================================================================= ===========
File: driver.c status: up-to-Date
Version: 1.7 Sat Dec 5 18:25:54 1992
RCS Version: 1.7 /u/cvsroot/yoyodyne/tc/driver.c ,v
Sticky Tag: Rel-1-0-Patches (Branch: 1.7.2)
Sticky Date: (NONE)
Sticky Options: (NONE)
EXInship tags:
Rel-1-0-Patches (Branch: 1.7.2)
Rel-1-0 (Revision: 1.7)
============================================================================================================================================================================================================= ===========
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: Rel-1-0-Patches (Branch: 1.4.2) Sticky Date: (NONE)
Sticky Options: (NONE)
EXInship tags:
Rel-1-0-Patches (Branch: 1.4.2)
Rel-1-0 (Revision: 1.4)
Rel-0-4 (Revision: 1.4)
Don't be confused by the branch number of each file (`1.7.2 'and` 1.4.2'), the branch is the decision by the branch mark to be 'Rel-1-0-Patches'. The branch here only indicates the revision number of each file when the branch is generated. Branches and revised numbers are usually in the case where the files in the source code library are increased in linearity: ----- ---- --- ----- ---- ! 1.1! ----! 1.2! ----! 1.3! ----! 1.4! ----! 1.5! ---- ----- ---- ----- --- But CVS is not limited to linear development, the source tree may have a branch, each branch is an opposite development line. The modification of the branch is easily added to the main branch. Each branch has a branch number, which is represented by a number of odd numbers that use ".". The branch is achieved by adding an integer after generating a revision number at the branch. By defining a branch number, a plurality of development branches are divided from the same branch point. The revision number of the branch is obtained by adding a numeric suffix in the order of the branch, as shown below: The detailed details of the branch number are actually not well understood, but understanding its working principle is necessary: When CVS creates a branch It selects a minimum even as a branch suffix. Therefore, when a branch is hoped from the revision number 6.4, the branch number of the new branch is 6.4.2. All branch numbers as a branch suffix are reserved by CVS (for example, 6.4.0). After a merge branch, it is often necessary to combine the revision into the main branch for a while, and can be used through the `-j branchname 'parameters. Use this parameter to merge branches and their parent branches. Consider the following source revision tree: Branch 1.2.2 is defined as tag R1FIX. The following example hypothesis MOD only contains a file MC: $ cvs checkout mod # Get the latest version 1.4 $ cvs Update -j R1Fix MC # All updates to the main branch # is also 1.2 to 1.2.2.2 modification to Current Work Copy $ CVS Commit -m "Included R1Fix" # Create a revision 1.5. Merge may occur, if a conflict occurs, you should handle conflicts before committing. The checkout command also supports parameters `-j branchname ', the above operation can be implemented by the following command;
$ cvs checkout -j r1fix mod
$ cvs commit -m "incruded r1fix"
One need to pay attention is "Update -j Tagname" can also include reference: http://www.cvshome.org/docs/manual/cvs.html
