What is cvs in linux

In Linux, the full name of cvs is "Concurrent Version System", which means "code version control software" in Chinese. It is a GNU software package mainly used for source code maintenance in a multi-person development environment. CVS can maintain the development and use of any document, such as the editing and modification of shared files, not just programming; the file types maintained by CVS can be text or binary. The client/server based behavior of CVS allows it to accommodate multiple users.

#The operating environment of this tutorial: linux7.3 system, Dell G3 computer.

cvs in Linux

CVS (Concurrent Versions System, code version control software) is a GNU software package mainly used for Maintenance of source code in a multi-person development environment. A code version control software similar to it is subversion. Multiple developers record file versions through a central version control system to ensure file synchronization. CVS version control system is a GNU software package mainly used for source code maintenance in a multi-person development environment. However, due to previous problems with CVS coding, most software development companies have used SVN instead of CVS.

Concurrent has the meaning of concurrency, collaboration, and consistency. In fact, CVS can maintain the development and use of any document, such as the editing and modification of shared files, not just limited to programming. The file types maintained by CVS can be text or binary.

CVS uses the Copy-Modify-Merge (copy, modify, merge) change table to support simultaneous access and modification of files. It explicitly separates the storage of source files from the user's workspace and enables them to operate in parallel.

CVS's client/server based behavior allows it to accommodate multiple users. This feature makes CVS the first choice when people in different locations work on data files (especially the source code of a program) at the same time.

Working Ideas

Establish a source code library on a server, which can store source programs for many different projects. These source programs are managed uniformly by the source code repository administrator. Before each user uses the source code library, he must first download the project file in the source code library to the local. Then the user can modify it locally, and finally submit it with the CVS command, and the CVS source code library will uniformly manage the modifications. In this way, it is as if only one person is modifying the file, which avoids conflicts and can track file changes.

CVS stands for Concurrent Versions System, a mainstream open source network transparent version control system. CVS is useful for everyone from individual developers to large, distributed teams.

Its client/server access method allows developers to access the latest code from any Internet access point. Its unrestricted version management checkout (check out: Note 1) mode avoids the usual manual conflicts caused by the exclusive checkout mode. Its client tools can be used on most platforms.

CVS is used in popular open source projects, such as Mozilla, GIMP, XEmacs, KDE and GNOME, etc. So what is it like.

You might say, it's great, but for "me" it doesn't do much. First, the basics: a version control system maintains a history of changes made to a series of files. For a developer, that means being able to track all the changes you make to a program throughout its development. Have you ever had a day's work wasted because you pressed the wrong key on the command line? Version control systems give you a secure network.

Version control systems are useful for anyone, really. (After all, who wouldn’t want to use a secure network.) They are frequently used by software development teams. Developers working in teams need to be able to adjust their individual changes; a centralized version control system allows that.

Code Adjustment

In a traditional version control system, a developer checks out a file, modifies it, and then checks it back in. The developer who checks out the file has exclusive rights to modify the file. No other developer can check out the file -- and only the developer who checked out that file can check in (note 2) the changes. (Of course there are many ways for administrators to exceed this limit.)

Think about how an exclusive checkout might work: Bob's brother checks out foo.java so he can add comments, and after writing the code, what does he do? Didn't do it either. Then he went to have lunch. After Bob finished lunch, he found that a bug pointed out to him by his boss was in foo.java. He tries to check out foo.java... but the version control system won't let him because his brother has already checked it out. Bob had to wait for his brother to come back from lunch (which took two hours on this "good" day) so that he could fix the bug.

In a large open source project, where developers may be working late in any time zone, giving one developer the ability to prevent other developers anywhere from continuing to work on any file obviously doesn't work. They will eventually get bored of not being able to work on projects when they want to.

CVS solves this problem through its unlimited checkout mode. Checking out a file does not give the developer exclusive rights to that file. Other developers can also check it out, make their own changes, and check it back in.

"Wait a minute" you might say. "But won't the subsequent registration overwrite the previous one?" The answer is no. The detailed answer is that when multiple developers make changes to the same file, CVS will detect it and automatically merge those changes.

Wow. Automatically, don't worry - CVS will be careful and will automatically merge changes as long as they are not made to the same line of code. If CVS cannot handle these changes safely, developers will have to merge them manually. Where to go from here.

There are a large number of add-ons for CVS available on many platforms that add functionality to CVS or make CVS easier to use.

Benefits of using

• When you modify the software, you may unknowingly mix in some bugs, and it may take a long time for you to notice them. The presence. With cvs, you can easily restore an old version and see which modification caused the bug. Sometimes this is useful.

• cvs uses a clever way to save all versions of a file in one file, saving only the differences between different versions.

• cvs was originally published as a shell script by Dick Grune in the comp.sources.unix newsgroup volume 6 in December 1986; designed by Brian Berliner in April 1989 Got cvs and wrote the code. Jeff Polk then helped Brian design the cvs module and vendor branch support.

• cvs cannot guide you on how to construct what. It just saves a tree structure file you designed for recovery purposes.

• cvs cannot decide how to use disk space in a checkout working directory. If you write Makefiles or scripts in every directory and have to know the relative location of everything else, you sometimes have to check out the entire repository.

• If you modularize your work and set up a build system that shares files (via links, mounts, VPATH in Makefiles, etc.), you can arrange the disks as you like. use.

• You should put a tool under cvs to support such a build system (scripts, Makefiles, etc.).

• When some changes occur outside the scope of cvs, think about what files need to be rebuilt. A traditional method is to use make to construct and use some automated tools to generate related files used by make.

Related recommendations: "Linux Video Tutorial"

The above is the detailed content of What is cvs in linux. For more information, please follow other related articles on the PHP Chinese website!