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

How to use CVS for version control, in view of this problem, this article introduces the corresponding analysis and answers in detail, hoping to help more partners who want to solve this problem to find a more simple and easy way.

The GitHub website was released in 2008. If your career as a software engineer is later than mine, Git is probably the only version control software you've ever used. Although its steep learning curve and unintuitive user interface are often complained about, it is undeniable that Git has become the choice of everyone learning version control. There is no difference between cvs and Git. Today we will introduce the predecessor of Git-cvs.

A 2015 developer survey conducted by Stack Overflow showed that 69.3% of respondents were using Git, almost double the number of users of Subversion version control system, which ranked second. After 2015, perhaps because Git was so popular that people were no longer interested in the topic, Stack Overflow stopped conducting questionnaires about the version control systems used by developers.

The release time of GitHub is very close to the release time of Git itself. In 2005, Linus Torvalds released the first version of Git. It may be hard for today's senior developers to imagine that the word "version control software" represents more than just Git, even though it hasn't been around for a long time. Besides Git, there are many other options. At that time, open source developers preferred Subversion, enterprises and video game companies used Perforce (some still do), and the Linux kernel project relied on a version control system called BitKeeper.

Some of these systems, especially BitKeeper, will make the younger generation of Git users feel familiar and quick to use, but most of them are very different. Except for the previous version control systems of BitKeeper,Git, they all run on the basis of different architectural models. Eric Sink, the author of Version Control By Example, classifies version control in his book. According to him, Git belongs to the third generation version control system, while most of the predecessor of Git, that is, the system popular in the 1990s and early 21 century, belongs to the second generation version control system. (2) the third generation version control system is distributed and the second generation is centralized. You've probably heard before that Git is described as a "distributed" version control system. I never understood the difference between distributed and centralized, so I installed a second-generation centralized version of the control system myself, and did some experiments, at least some of it.

The version system I installed is CVS. CVS, the abbreviation for "concurrent version system Concurrent Versions System", is the original second-generation version control system. It was the most popular version control system for about a decade until it was replaced by Subversion in 2000. Even so, Subversion is considered to be a "better CVS", which further highlights the dominance of CVS in the 1990s.

CVS was first developed by a Dutch scientist named Dick Grune in 1986, when he had a compiler project and he was looking for a way to work with his students. 3 CVS was originally just a collection of Shell scripts packaged with RCS (revision Control system Revision Control System), and Grune wanted to improve this first-generation version control system. RCS works in pessimistic lock mode, which means that two programmers cannot work on the same file at the same time. If you need to edit a file, you must first request an exclusive lock from the RCS system and lock the file until you have finished editing it. If you want to edit the file that someone is editing, you must wait. CVS improved on the basis of RCS, and replaced the pessimistic lock model with the optimistic lock model, ushering in the era of the second generation version control system. Programmers can now edit the same file at the same time, merge the editing parts, and then resolve the merge conflict. Brian Berliner, the engineer who later took over the CVS project, wrote a very easy-to-read paper on CVS innovation in 1990. )

In this sense, there is no difference between CVS and Git, because Git also runs in optimistic locking mode, but it is only similar. In fact, when Linus Torvalds developed Git, one of his guiding principles was WWCVSND, "What Would CVS Not Do that CVS cannot do." Whenever he makes a decision, he strives to choose functional options that are not used in CVS design. 4 so even though CVS is more than ten years earlier than Git, its impact on Git is negative.

I like messing with CVS very much. I think there's no better way to figure out why Git's distributed nature is a huge improvement on previous version control systems than messing with CVS. So I invite you to join me on an exciting journey and learn about this software that has been unused for nearly a decade in the next ten minutes. (you can take a look at the "revision" section at the end of the article)

Getting started with CVS

Installation tutorials for CVS can be found on its project home page. For MacOS systems, you can install them using Homebrew.

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 <-- favorites.txtnew revision: 1.2; previous revision: 1.1

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 < green7,10d5

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.