Shulou(Shulou.com)06/01 Report--

This article mainly introduces the relevant knowledge of what the CVS version control method is, the content is detailed and easy to understand, the operation is simple and fast, and it has a certain reference value. I believe you will gain something after reading this CVS version control method. Let's take a look at it.

CVS is a Cramp S system, in which multiple developers record file versions through a central version control system, so as to ensure file synchronization. CVS version control system is a GNU software package, which is mainly used for source code maintenance in multi-person development environment.

Getting started with CVS

Because CVS is centralized, there is a distinction between the client and the server, which Git does not have. There are different executables at both ends, and the difference is not obvious. But to start using CVS, you must set up the service backend of CVS, even if it is only used on your local machine.

The back end of the CVS, the central repository for all code, is called the repository repository. Every project in Git has a repository, while one repository in CVS contains all the projects. Although there are ways to ensure that only one project can be accessed at a time, a central repository that contains everything cannot be changed.

To create the repository locally, run the init command. You can create a directory at home as shown below, or anywhere in your local area.

$cvs-d ~ / sandbox init

CVS allows you to pass options to the cvscvs command itself or to the init subcommand. The options that appear after the cvs command are global by default, while those that appear after the subcommand are subcommand-specific options. In the example shown above, the-d flag is a global option. Here we tell CVS where we want to create the repository path, but the general-d flag refers to the repository location that we want to use and already exists. Using the-d flag all the time is tedious, so you can set the CVSROOT environment variable instead.

Because we are only operating locally, we can just use the-d reference to pass the path, but it can also include a hostname.

This command creates a directory called sandbox in your home directory. If you list the sandbox content, you will find that the following contains a directory named CVSROOT. Please do not confuse this directory with our environment variables, which hold the management files for the repository.

Congratulations! You just created your first CVS repository.

Check in code

Suppose you decide to keep a list of colors you like. Because you are an artistic but forgetful person, you type a list of colors and save them in a file called favorites.txt:

Blueorangegreendefinitely not yellow

We also assume that you save the file to a directory called colors. Now you want to put the list of favorite colors under version control, because fifty years from now you will look back on how your tastes have changed over time.

To do this, you must import your directory as a new CVS project. You can use the import command:

$cvs-d ~ / sandbox import-m "" colors colors initialN colors/favorites.txtNo conflicts created by this import

Here we use the-d flag again to specify the location of the repository, and the rest of the parameters are passed to the import subcommand. A message must be provided, but it is not necessary here, so leave it blank. The next parameter, colors, specifies the name of the new directory in the repository, and the name given here is the same as the directory name checked in. The last two parameters specify the "vendor" tag and the "release" tag, respectively. We'll talk about tags later. We just pulled the colors project into the CVS repository. There are many different ways to introduce code into CVS, but this is recommended by Pragmatic Version Control Using CVS, a practical guide for programmers on CVS. The embarrassing thing about using this method is that you have to check out the check out work item again, even if the colors project already exists. Do not use this directory, first delete it, and then check out the previous version from CVS, as shown below:

$cvs-d ~ / sandbox co colorscvs checkout: Updating colorsU colors/favorites.txt

This process creates a new directory, also called colors. You will find your source file favorites.txt in this directory, as well as a directory called CVS. This CVS directory is basically equivalent to the. git directory of each Git repository.

Make changes

Get ready for the trip.

Like Git, CVS has a status command:

$cvs statuscvs status: Examining. = File: favorites.txt Status: Up-to-date Working revision: 1.1.1.1 2018-07-06 19:27:54-0400 Repository revision: 1.1.1.1 / Users/sinclairtarget/sandbox/colors/favorites.txt,v Commit Identifier: fD7GYxt035GNg8JA Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none)

Things are starting to get strange here. CVS does not have the concept of submitting objects. As shown above, there is something called "submission identifier Commit Identifier", but this may be a newer version of the logo, and the concept of "submission identifier" was not mentioned in the book Pragmatic Version Control Using CVS published in 2003. The latest version of CVS was released in 2008. 5)

In Git, the version of a file we are talking about is actually talking about something related to commit 45de392, while the Chinese version of CVS is an independent version. The first version of the file is version 1.1, the next is version 1.2, and so on. When branches are involved, extended numbers are added later. So you will see 1.1.1.1 as shown above, which is the version number of the example, even if we did not create a branch, it seems to be added by default.

There will be many files and many submissions in a project, and if you run the cvs log command (equivalent to git log), you will see the submission history of each file. In the same project, it is possible that one file is in version 1.2 and one file is in version 1.14.

Go on, let's make some changes to the version 1.1 favorites.txt file (LCTT translation note: there is an error in the example here):

Blueorangegreencyandefinitely not yellow

Once the modification is complete, you can run cvs diff to see what happens to CVS:

$cvs diffcvs diff: Diffing .Index: favorites.txt=RCS file: / Users/sinclairtarget/sandbox/colors/favorites.txt,vretrieving revision 1.1.1.1diff-r1.1.1.1 favorites.txt3a4 > cyan

CVS recognized us that I added a new line containing the color "cyan" to the file. (in fact, it says that we have made changes to the "RCS" file; as you can see, the underlying CVS is still using RCS. ) this difference refers to the difference between the copy of favorites.txt in the current working directory and the version 1.1.1.1 files in the repository.

In order to update the version in the repository, we must commit the changes. In Git, this operation takes several steps. First, save the change temporarily so that it appears in the index, then commit the change, and finally, in order for the change to be visible to others, we must push the commit to the source repository.

In CVS, you only need to run the cvs commit command to get everything done. CVS aggregates the changes it finds and puts them in the repository:

$cvs commit-m "Add cyan to favorites." cvs commit: Examining. / Users/sinclairtarget/sandbox/colors/favorites.txt,v

I'm used to Git, so this kind of operation scares me very much. Because there is no mechanism to change the staging area, anything you touch in the working directory will be submitted to the public repository. Have you ever rewritten a bad function implementation of a colleague in private because you were upset, but just let yourself out and didn't want him to know? If you accidentally submit it, it will be too bad, he will think you are an asshole. You can't edit a submission before you push them, because a submission is a push. Or would you rather spend 40 minutes running the git rebase-I command repeatedly to make the local submission history as clear and rigorous as the mathematical proof? Unfortunately, it's not supported in CVS, and as a result, everyone will see that you didn't write test cases first.

But now I finally understand why so many people think that Git doesn't have to be so complicated. For those who are already accustomed to direct cvs commit, doing staging and pushing changes is a pointless task.

People often talk about Git as a "distributed" system, in which the main difference between distributed and non-distributed is that local commit cannot be done in CVS. The commit operation is to submit the code to the central repository, so you cannot perform the operation without a network connection, and your local ones are just your working directory; in Git, there will be a complete local repository, so you can perform the commit operation without interruption even if the network is offline. You can also edit those submissions, rollbacks, branches, and choose what you want, and no one will know anything other than what they need to know.

Because submitting is a big deal, CVS users rarely do it. Submissions can contain a lot of content changes, as we can now see in a pull request with ten submissions. This is especially true if the submission triggers the CI build and automated test program.

Now that we run cvs status, we will see that a new version of the file is generated:

Cvs statuscvs status: Examining. = File: favorites.txt Status: Up-to-date Working revision: 1.21.2-07-06 21:18:59-0400 Repository revision: 2018 / Users/sinclairtarget/sandbox/colors/favorites.txt,v Commit Identifier: pQx5ooyNk90wW8JA Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) merge

As mentioned above, in CVS, you can edit files that others are editing at the same time. This is a major improvement to RCS by CVS. What happens when you need to put the changed parts back together?

Suppose you invite some friends to add their favorite colors to your list. When they add, you make sure you no longer like green, and then remove it from the list.

When you submit an update, you will find that CVS has reported a problem:

$cvs commit-m "Remove green" cvs commit: Examining .cvs commit: Up-to-date check failed for `favorites.txt'cvs [commit aborted]: correct above errors first!

It looks like friends submitted their changes first. So your favorites.txt file version is not updated to the latest version in the repository. When you run cvs status, you can see that the local copy of the favorites.txt file has some local changes and is version 1.2, while the version number on the repository is 1.3, as shown below:

Cvs statuscvs status: Examining. = File: favorites.txt Status: Needs Merge Working revision: 1.21.2-07-07 10:42:43-0400 Repository revision: 2018 / Users/sinclairtarget/sandbox/colors/favorites.txt,v Commit Identifier: 2oZ6n0G13bDaldJA Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none)

You can run cvs diff to see the exact difference between version 1.2 and version 1.3:

$cvs diff-r HEAD favorites.txtIndex: favorites.txt=RCS file: / Users/sinclairtarget/sandbox/colors/favorites.txt,vretrieving revision 1.3diff-r1.3 favorites.txt3d2

It seems that our friends really like pink, but fortunately they are editing different parts of the file, so it is easy to merge this change. Similar to git pull, CVS can merge for us by running the cvs update command, as shown below:

$cvs updatecvs update: Updating .RCS file: / Users/sinclairtarget/sandbox/colors/favorites.txt,vretrieving revision 1.2retrieving revision 1.3Merging differences between 1.2 and 1.3 into favorites.txtM favorites.txt

If you look at the contents of the favorites.txt file at this point, you will find that your friend's changes to the file have been included, and your changes are also included. Now you are free to submit documents, as shown below:

$cvs commitcvs commit: Examining. / Users/sinclairtarget/sandbox/colors/favorites.txt,v

The end result is the same as running git pull-rebase in Git. Your changes are added after your friend's changes, so there is no "merge commit" operation.

In some cases, changes to the same file can lead to conflicts. For example, if your friend changes "green" to "olive" and you delete "green" completely, there will be a conflict. In the early days of CVS, it was this situation that led to concerns about CVS insecurity, and RCS's pessimistic locking mechanism ensured that this would never happen. But CVS provides a security mechanism to ensure that no one's changes are automatically overwritten. Therefore, when running cvs update, you must tell CVS which changes you want to keep before you can proceed to the next step. CVS marks all changes to the file in the same way that Git detects a merge conflict, and then you have to manually edit the file and select the changes that need to be retained to merge. The interesting thing to note here is that conflicts must be fixed and merged before committing. This is another result of the centralized nature of CVS. In Git, you don't have to worry about merge conflicts until you push local submissions.

Marking and branching

Since CVS does not have an easily addressable commit object, the only way to group change sets is to mark the state of a specific working directory.

It is easy to create a tag:

$cvs tag VERSION_1_0cvs tag: Tagging .T favorites.txt

Later, you can restore the file to this state by running the cvs update command and transferring the tag to the-r flag, as shown below:

$cvs update-r VERSION_1_0cvs update: Updating .U favorites.txt

Because you need a tag to go back and forth to the early working directory state, CVS encourages the creation of a large number of preemptive tags. For example, before a major refactoring, you can create a BEFORE_REFACTOR_01 tag that you can use to fallback if the refactoring goes wrong. You can also use tags if you want to generate difference files for the entire project. Basically, everything we do with submitted hashes these days must be planned ahead of time in CVS, because you have to have a tag first.

You can create branches in CVS. A branch is just a special tag, as shown below:

$cvs rtag-b TRY_EXPERIMENTAL_THING colorscvs rtag: Tagging colors

This command simply creates a branch (everyone thinks so), so you also need to use the cvs update command to switch branches, as shown below:

$cvs update-r TRY_EXPERIMENTAL_THING

The above command will change your current working directory to a new branch, but Pragmatic Version Control Using CVS actually suggests creating a new directory to house your new branch. Presumably, the author found it easier to switch directories than branches in CVS.

This book also recommends that you do not create branches from existing branches, but only on mainline branches (called master in Git). Generally speaking, branches are considered "advanced" skills in CVS. In Git, you are almost free to create a new branch, but in CVS you can only create it when you really need it, such as releasing a project.

You can later merge the branches back to the mainline using the cvs update and-j flags:

This is the end of $cvs update-j TRY_EXPERIMENTAL_THING 's article on "what is the CVS version control method?" Thank you for reading! I believe that everyone has a certain understanding of the knowledge of "what is the CVS version control method". If you want to learn more knowledge, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.