Are you an EPFL student looking for a semester project?
Work with us on data science and visualisation projects, and deploy your project as an app on top of Graph Search.
Concept
Concurrent Versions System
Summary
Concurrent Versions System (CVS, also known as the Concurrent Versioning System) is a revision control system originally developed by Dick Grune in July 1986.
CVS operates as a front end to RCS, an earlier system which operates on single files. It expands upon RCS by adding support for repository-level change tracking, and a client-server model.
Released under the terms of the GNU General Public License, CVS is free software.
CVS operates as a front end to Revision Control System (RCS), an older version control system that manages individual files but not whole projects. It expands upon RCS by adding support for repository-level change tracking, and a client-server model. Files are tracked using the same history format as in RCS, with a hidden directory containing a corresponding history file for each file in the repository.
CVS uses delta compression for efficient storage of different versions of the same file. This works well with large text files with few changes from one version to the next. This is usually the case for source code files. On the other hand, when CVS is told to store a file as binary, it will keep each individual version on the server. This is typically used for non-text files such as executable images where it is difficult to create compact deltas between versions.
CVS excludes symbolic links because when they are stored in a version control system they can pose a security risk. For instance, a symbolic link to a sensitive file can be stored in the repository, making the sensitive file accessible even when it is not checked in. In place of symbolic links, scripts that require certain privileges and conscious intervention to execute may be checked into CVS.
CVS labels a single project (set of related files) that it manages as a module. A CVS server stores the modules it manages in its repository. Programmers acquire copies of modules by checking out. The checked-out files serve as a working copy, sandbox or workspace. Changes to the working copy are reflected in the repository by committing them.
Official source
About this result
This page is automatically generated and may contain information that is not correct, complete, up-to-date, or relevant to your search query. The same applies to every other page on this website. Please make sure to verify the information with EPFL's official sources.