Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Jump to content

Concurrent Versions System: Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous edit
Content deleted Content added
VisualWikitext
Removed text on active development. It is not realistic to say CVS is in active development, just look at the reference. Few changes in years. It is definitely not active.
Tag: references removed
→External links: Pruned external links to meet WP:EL.
 
(244 intermediate revisions by more than 100 users not shown)
Line 1: Line 1:
{{Short description|Historical centralized version control system}}
{{lead too short|date=September 2018}}
{{Infobox software
{{Infobox software
| logo =
| name = Concurrent Versions System
| screenshot =
| logo =
| caption =
| screenshot =
| developer = [http://savannah.nongnu.org/project/memberlist.php?detailed=1&group=cvs The CVS Team]
| caption =
| released = {{Start date and age|1990|11|19}}
| developer = [http://savannah.nongnu.org/project/memberlist.php?detailed=1&group=cvs The CVS Team]
| latest release version = 1.11.23<ref>[https://savannah.nongnu.org/news/?id=5273 Stable CVS Version 1.11.23 Released!]</ref>
| released = {{Start date and age|1990|11|19}}
| latest release version = 1.11.23
| latest release date = {{Start date and age|2008|05|08}}
| latest preview version = 1.12.13<ref>[https://savannah.nongnu.org/news/?id=4010 CVS Feature Version 1.12.13 Released! * Security Update *]</ref>
| latest release date = {{Start date and age|2008|05|08}}
| latest preview version = 1.12.13
| latest preview date = {{Start date and age|2005|09|28}}
| operating system = [[Unix-like]], [[Microsoft Windows|Windows]]
| latest preview date = {{Start date and age|2006|07|26}}
| platform =
| operating system = [[Unix-like]], [[Microsoft Windows|Windows]]
| programming language = [[C (programming language)|C]]
| platform =
| genre = [[Revision control]]
| programming language = [[C (programming language)|C]]
| license = [[GNU General Public License|GPL-1.0-or-later]]<ref>{{cite web|url=https://cvs.savannah.nongnu.org/viewvc/cvs/ccvs/README?view=markup|title=Contents of /ccvs/README}}</ref>
| genre = [[Revision control]]
| website = {{URL|http://cvs.nongnu.org}}
| license = [[GNU General Public License]]
| website = {{URL|http://savannah.nongnu.org/projects/cvs}}
}}
}}


'''Concurrent Versions System''' ('''CVS''', or '''Concurrent Versioning System''') is a [[version control system]] originally developed by [[Dick Grune]] in July 1986.<ref name="ximbiot" />
The '''Concurrent Versions System''' ('''CVS'''), also known as the '''Concurrent Versioning System''', is a client-server [[free software]] [[revision control]] system in the field of [[software development]]. Version control system software keeps track of all work and all changes in a set of files, and allows several developers (potentially widely separated in space and/or time) to [[collaboration|collaborate]]. [[Dick Grune]] developed CVS as a series of [[shell scripts]] in July 1986. There was a similar system available earlier in the mid-70's developed by John Humbert.<ref>{{cite web|url=http://ximbiot.com/cvs/wiki/CVS--Concurrent%20Versions%20System%20v1.12.12.1:%20Overview|title=CVS--Concurrent Versions System v1.12.12.1: Overview|publisher=CVS Wiki|accessdate=12 December 2009}}</ref>


== Design ==
CVS became popular with commercial software developers and also the [[open source software]] world and is released under the [[GNU General Public License]].


CVS operates as a [[front end and back end|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.<ref name="Stopak" /> 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.
== Features ==


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''' uses a [[client–server]] architecture: a server stores the current version(s) of a [[project]] and its history, and clients connect to the server in order to "check out" a complete copy of the project, work on this copy and then later "check in" their changes. Typically, the client and server connect over a [[local area network|LAN]] or over the [[Internet]], but client and server may both run on the same machine if CVS has the task of keeping track of the version history of a project with only local developers. The server software normally runs on [[Unix]] (although at least the [[CVSNT]] server also supports various flavors of [[Microsoft Windows]]), while CVS clients may run on any major [[operating system|operating-system]] platform.


CVS excludes [[symbolic link]]s 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.{{citation needed|reason=cleanup of text|date=July 2017}}
Several developers may work on the same project concurrently, each one editing files within their own "working copy" of the project, and sending (or ''checking in'') their modifications to the server. To avoid the possibility of people stepping on each others' toes, the server will only accept changes made to the most recent version of a file. Developers are therefore expected to keep their working copy up-to-date by incorporating other people's changes on a regular basis. This task is mostly handled automatically by the CVS client, requiring manual intervention only when an [[edit conflict]] arises between a checked-in modification and the yet-unchecked local version of a file.


== Operation ==
If the check in operation succeeds, then the version numbers of all files involved automatically increment, and the CVS-server writes a user-supplied description line, the date and the author's name to its [[data logging|log]] files. CVS can also run external, user-specified log processing scripts following each commit. These scripts are installed by an entry in CVS's <tt>loginfo</tt> file, which can trigger email notification or convert the log data into a Web-based format.


CVS labels a single project (set of related files) that it manages as a ''[[module (programming)|module]]''. A CVS server stores the modules it manages in its ''[[information repository|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 ''[[commit (data management)|committing]]'' them. To ''update'' is to acquire or ''[[merge (revision control)|merge]]'' the changes in the repository with the working copy.
Clients can also compare versions, request a complete history of changes, or check out a historical snapshot of the project as of a given date or as of a revision number.


CVS uses a [[client–server]] architecture: a server stores the current version(s) of a [[project]] and its history, and clients connect to the server in order to "check out" a complete copy of the project, work on this copy and then later "check in" their changes. CVS servers can allow "anonymous read access",<ref name="anoncvs" /> wherein clients may check out and compare versions with either a blank or simple published password (e.g., "anoncvs"); only the check-in of changes requires a personal account and password in these scenarios. Several developers may work on the same project concurrently, each one editing files within their own "working copy" of the project, and sending (or ''checking in'') their modifications to the server. To avoid conflicts, the server only accepts changes made to the most recent version of a file. Developers are therefore expected to keep their working copy up-to-date by incorporating other people's changes on a regular basis. This task is mostly handled automatically by the CVS client, requiring manual intervention only when an [[edit conflict]] arises between a checked-in modification and the yet-unchecked local version of a file. Clients can also use the "update" command to bring their local copies up-to-date with the newest version on the server. Clients can also compare versions, request a complete history of changes, or check out a historical snapshot of the project (e.g.: based on a given date). If the check-in operation succeeds, then the version numbers of all files involved automatically increment, and the server writes a user-supplied description line, the date and the author's name to its [[data logging|log]] files. CVS can also run external, user-specified log processing scripts following each commit. These scripts are installed by an entry in CVS's <code>loginfo</code> file, which can trigger email notification or convert the log data into a Web-based format.
==== Anonymous CVS ====
Many [[open source|open-source]] projects allow "anonymous read access", a feature pioneered by [[OpenBSD]]. This means that clients may check out and compare versions with either a blank or simple published password (e.g., "anoncvs"); only the check-in of changes requires a personal account and password in these scenarios.


CVS can also maintain different "branches" of a project. For instance, a released version of the software project may form one branch, used for bug fixes, while a version under current development, with major changes and new features, can form a separate branch. CVS assumes that the majority of work takes place on the trunk, and that branches should generally be short-lived or historical. When used as designed, branches are easily managed and branch operations are efficient and fast.<ref name="Collins-Sussman" /><ref name="West" />
Clients can also use the "update" command in order to bring their local copies up-to-date with the newest version on the server. This eliminates the need for repeated downloading of the whole project.


== Portability ==
CVS can also maintain different "branches" of a project. For instance, a released version of the software project may form one branch, used for bug fixes, while a version under current development, with major changes and new features, can form a separate branch.


The server software normally runs on [[Unix]] (although at least the [[CVSNT]] server also supports various flavors of [[Microsoft Windows]]), while CVS clients may run on any major [[operating system]] platform.
CVS uses [[delta compression]] for efficient storage of different versions of the same file. The implementation favors files with many lines (usually text files) - in extreme cases the system may store individual copies of each version rather than deltas.


== History ==
{{Quotation|In the world of open source software, the Concurrent Version System (CVS) has long been the tool of choice for version control. And rightly so. CVS itself is free software, and its non-restrictive ''modus operandi'' and support for networked operation – which allow dozens of geographically dispersed programmers to share their work – fits the collaborative nature of the open-source world very well. CVS and its semi-chaotic development model have become cornerstones of open-source.|Collins-Sussman|Version Control with Subversion For Subversion 1.1, 2005}}
Grune recalled:<ref name="Grune" />

{{ quotation
== Terminology ==
| I created CVS to be able to cooperate with my students, Erik Baalbergen and Maarten Waage, on the ACK ([[Amsterdam Compiler Kit]]) C compiler. The three of us had vastly different schedules (one student was a steady 9-5 worker, the other was irregular, and I could work on the project only in the evenings). Their project ran from July 1984 to August 1985. CVS was initially called cmt, for the obvious reason that it allowed us to commit versions independently.
CVS labels a single project (set of related files) which it manages as a ''[[module (programming)|module]]''. A CVS server stores the modules it manages in its ''[[information repository|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 will be reflected in the repository by ''[[Commit (data management)|committing]]'' them. To ''update'' is to acquire or ''[[Merge (revision control)|merge]]'' the changes in the repository with the working copy.

== History and status ==

CVS developed from an earlier versioning-system called [[Revision Control System]] (RCS) ({{As of|2008|alt= still}} in use) which manages individual files but not whole projects. Dick Grune has provided some [http://www.cs.vu.nl/~dick/CVS.html#History brief historical notes] about CVS on his site. To quote:

{{Quotation|I created CVS to be able to cooperate with my students, Erik Baalbergen and Maarten Waage, on the ACK ([[Amsterdam Compiler Kit]]) C compiler. The three of us had vastly different schedules (one student was a steady 9-5 worker, the other was irregular, and I could work on the project only in the evenings). Their project ran from July 1984 to August 1985. CVS was initially called cmt, for the obvious reason that it allowed us to commit versions independently.|Dick Grune|[http://www.cs.vu.nl/~dick/CVS.html#History Dick Grune's website]
}}
}}
Grune publicly released the code to mod.sources on June 23, 1986: [[Google Groups]] continues to archive and serve the original [http://groups.google.com/group/mod.sources/msg/2ebab72ac0744fb8?dmode=source usenet post].


Grune publicly released the code on June 23, 1986.<ref name="mod.sources" />
The code that eventually evolved into the current version of CVS started with Brian Berliner in April 1989, with later input from Jeff Polk and many other contributors. Brian Berliner wrote [http://citeseer.ist.psu.edu/berliner90cvs.html a paper] introducing his improvements to the CVS program which describes how the tool was extended and used internally by Prisma, a third-party developer working on the SunOS kernel, and was released for the benefit of the community under the GPL. On November 19, 1990, CVS version 1.0 was submitted to the [[Free Software Foundation]] for development and distribution.<ref>[http://cvs.savannah.gnu.org/viewvc/ccvs/NEWS?revision=1.1&root=cvs&view=markup initial release of version 1.0; CVS NEWS file]</ref>


The code that eventually evolved into the current version of CVS started with Brian Berliner in April 1989, with later input from Jeff Polk and many other contributors. Brian Berliner wrote a paper introducing his improvements to the CVS program—which describes how the tool was extended and used internally by Prisma, a third-party developer working on the SunOS kernel, and was released for the benefit of the community under the GPL.<ref name="Berliner" /> On November 19, 1990, CVS version 1.0 was submitted to the [[Free Software Foundation]] for development and distribution.<ref name="1.0" />
CVS introduced the implementation of [[Branching (software)|branching]] into version control systems: the branching techniques in other systems all derive from the CVS implementation as documented in 1990 <ref>[http://www.fnal.gov/docs/products/cvs/cvs-paper.ps CVS II: Parallelizing Software Development article by Brian Berliner ]</ref>. Whilst [[Revision Control System|RCS]] did incorporate the concept of [[Branching (software)|branches]] - they were for individual files only.


The latest version was released on 8 May 2008.<ref name="latestversion" />
CVS has always solidly supported distributed, multi-site and offline operations due to the unreliability of the few computer networks that existed at the time CVS evolved.


== Adoption and successors ==
Active development of CVS has apparently been discontinued, with the latest version released May 2008, and only some maintenance bugfixes since then in the CVS project's own CVS repository.<ref>{{cite web|url=http://cvs.savannah.gnu.org/viewvc/cvs/ccvs/ChangeLog|title=CVS ChangeLog|accessdate=May 25, 2009}}</ref>


{{ quotation
Development of the [[Microsoft Windows]] port of CVS has split off into a separate project named [[CVSNT]] and has been more active in extending the feature set of the system, even porting the changes back to the UNIX platform.
| In the world of open source software, the Concurrent Version System (CVS) has long been the tool of choice for version control. And rightly so. CVS itself is free software, and its non-restrictive ''modus operandi'' and support for networked operation—which allow dozens of geographically dispersed programmers to share their work—fits the collaborative nature of the open-source world very well. CVS and its semi-chaotic development model have become cornerstones of open-source.<ref name="svnbook" />
}}


Over time, developers have created new version control systems based on CVS in order to add features, alter the operational model, and improve developers' productivity. CVS replacement projects include [[CVSNT]] and [[Subversion (software)|Subversion]].<ref name="faq" /><ref name="FUD" />
=== Relationship with GNU ===


== See also ==
Historically, the relationship between CVS and the [[GNU]] project could appear somewhat ambiguous: the GNU Web site distributed the program, labelling it "GNU package" on one page and "other GPL-licensed project" on another. Clarification came {{As of|2008|alt= recently}} when CVS development moved from cvshome.org to savannah.nongnu.org, with CVS officially assigned to the non-gnu category. On the FTP site, the program has traditionally resided in the <code>/non-gnu/</code> directory and still does.
{{Portal|Free and open-source software}}
* [[Comparison of version-control software]]
* [[Cervisia]]
* [[OpenGrok]]
* [[StatCVS]]
* [[TortoiseCVS]]
* [[ViewVC]]


== Notes ==
{{Unreferenced section|date=March 2009}}


{{Reflist|refs=
== Criticism ==
<ref name="ximbiot">{{ cite web|url=http://ximbiot.com/cvs/manual/cvs-1.12.12/cvs_1.html|title=CVS--Concurrent Versions System v1.12.12.1: Overview|access-date=9 December 2011|archive-url=https://web.archive.org/web/20120415051926/http://ximbiot.com/cvs/manual/cvs-1.12.12/cvs_1.html|archive-date=15 April 2012|url-status=dead|df=dmy-all}}</ref>
The developers of CVS claim that many of the listed common criticisms of CVS were planned carefully and implemented intentionally into CVS:
<ref name="anoncvs">{{ cite web|author1=Charles D. Cranor|author2=Theo de Raadt|title=Opening The Source Repository With Anonymous CVS, USENIX 1999|url=http://www.openbsd.org/papers/anoncvs-paper.pdf |archive-url=https://ghostarchive.org/archive/20221009/http://www.openbsd.org/papers/anoncvs-paper.pdf |archive-date=2022-10-09 |url-status=live|date=1999}}</ref>
<ref name="Stopak">{{ cite web | title = The Evolution of Version Control System (VCS) Internals | first = Jacob | last = Stopak | date = November 30, 2019 | access-date = 22 September 2020 | url = https://initialcommit.com/blog/Technical-Guide-VCS-Internals }}</ref>
<ref name="Collins-Sussman">{{ cite web | last = Collins-Sussman | first = Ben | author2=Greg Ward | title = Subversion Users: Re: Performance (Subversion vs. CVS) | work = subversion-users | access-date = 2010-07-07 | date = September 2004 | url = http://svn.haxx.se/users/archive-2004-09/0681.shtml }}</ref>
<ref name="West">{{ cite web | last = West | first = Adrian | title = cvs branchtag performance fix | access-date = 2010-07-07 | date = July 2004 | url = http://www.adrianwest.org/cvs_perf_fix/cvs_perf_fix.htm | archive-url = https://web.archive.org/web/20090803183951/http://www.adrianwest.org/cvs_perf_fix/cvs_perf_fix.htm | archive-date = 2009-08-03 | url-status = dead }}</ref>
<ref name="mod.sources">{{ cite newsgroup |title=CVS, an RCS front-end (cvs) |author=Dick Grune |date=July 3, 1986 |newsgroup=mod.sources |message-id=122@mirror.UUCP |url=https://groups.google.com/group/mod.sources/msg/2ebab72ac0744fb8?dmode=source |access-date=September 14, 2016}}</ref>
<ref name="1.0">{{Cite web|url=http://cvs.savannah.gnu.org/viewvc/cvs/ccvs/NEWS?view=markup&revision=1.1|title=[cvs] Contents of /ccvs/NEWS|website=cvs.savannah.gnu.org}}</ref>
<ref name="Berliner">{{Cite web|archive-url=https://web.archive.org/web/20040909083546/http://citeseer.ist.psu.edu/berliner90cvs.html|title=CVS II: Parallelizing Software Development - Berliner (ResearchIndex)|archive-date=September 9, 2004|url=http://citeseer.ist.psu.edu/berliner90cvs.html}}</ref>
<ref name="latestversion">{{Cite web|url=http://savannah.nongnu.org/forum/forum.php?forum_id=5309|title=Concurrent Versions System - News: Stable CVS Version 1.11.23 Released! [Savannah]|website=savannah.nongnu.org}}</ref>
<ref name="faq">{{ cite web|url=http://subversion.apache.org/faq.html#why|title=Subversion FAQ: Why does this project exist?|publisher=[[Subversion (software)|Subversion]]|access-date=September 21, 2009}}</ref>
<ref name="Grune">{{Cite web|url=https://dickgrune.com/Programs/CVS.orig/|title=Concurrent Versions System CVS|website=dickgrune.com}}</ref>
<ref name="FUD">{{ cite web|url=http://www.red-bean.com/sussman/svn-anti-fud.html |title=Dispelling Subversion FUD |publisher=Ben Collins-Sussman |access-date=June 30, 2010 |url-status=dead |archive-url=https://web.archive.org/web/20110718233416/http://www.red-bean.com/sussman/svn-anti-fud.html |archive-date=July 18, 2011 }}</ref>
<ref name="svnbook">Ben Collins-Sussman, Version Control with Subversion For Subversion 1.1, 2005</ref>
}}


== References ==
* Revisions created by a commit are per file, rather than spanning the collection of files that make up the project or spanning the entire repository. At the occasional times that a release is made a tag can be performed to associate the set of revisions with a meaningful release name (e.g.: Office 2010).
* CVS does not version the moving or renaming of files and directories. It was implemented this way because in the past [[refactoring]] was avoided in development processes<ref>CVS began in 1984 and the first known paper to discuss refactoring was written in 1992</ref>. More recently the thinking has changed and refactoring can be managed by an administrator (by directly moving the RCS file in the repository, provided that the administrator knows what he or she is doing) as it is required
* No versioning of [[symbolic link]]s. Symbolic links stored in a version control system can pose a security risk - someone can create a symbolic link index.htm to /etc/passwd and then store it in the repository; when the "code" is exported to a Web server the Web site now has a copy of the system security file available for public inspection. A developer may prefer the convenience and accept the responsibility to decide what is safe to version and what is not; a project manager or auditor may prefer to reduce the risk by using build scripts that require certain privileges and conscious intervention to execute.
* Limited support for [[Unicode]] and non-ASCII filenames. Many Unix systems run in [[UTF-8]]<ref>{{Cite web
| last = Kuhn
| first = Markus
| title = UTF-8 and Unicode FAQ
| accessdate = 2010-07-07
| date = 2009-05-11
| url = http://www.cl.cam.ac.uk/~mgk25/unicode.html
}}</ref>, and so CVS on such systems handles UTF-8 filenames natively, but relying on native character sets can cause problems when multiple encodings are used (e.g. clients are running another [[Operating System|OS]], such as [[AS/400]] or legacy versions of [[Microsoft Windows|Windows]]).
* No atomic commit. The network and server used should have sufficient resilience that a commit can complete without ever crashing. In many code management processes, development work is performed on branches (for example, add feature A1234), and then merged into the trunk after code review - that final merge is 'atomic' and performed in the data center by QA. The term atomic is sometimes referred to in the transactional database sense where a commit will automatically roll back should it fail for any reason, and sometimes referred to in the sense that each commit can be uniquely identified. If each commit needs to be tracked then this can be handled by modifying the correct trigger.
* Expensive branch operations. CVS assumes that the majority of work will take place on the trunk — branches should generally be short-lived or historical. When used as designed, branches are easily managed and branch operations are efficient and fast <ref>{{Cite web
| last = Collins-Sussman
| first = Ben
| coauthors = Greg Ward
| title = Subversion Users: Re: Performance (Subversion vs. CVS)
| work = subversion-users
| accessdate = 2010-07-07
| date = 2004-09
| url = http://svn.haxx.se/users/archive-2004-09/0681.shtml
}}</ref><ref>{{Cite web
| last = West
| first = Adrian
| title = cvs branchtag performance fix
| accessdate = 2010-07-07
| date = 2004-07
| url = http://www.adrianwest.org/cvs_perf_fix/cvs_perf_fix.htm
}}</ref>.
* CVS treats files as textual by default. Text files should be the primary file type stored in the CVS repository. Binary files are supported and files with a particular file extension can automatically be recognized as being binary.
* No support for [[distributed revision control]] or unpublished changes. Programmers should commit changes to the files often for frequent merging and rapid publication to all users.


{{refbegin}}
Over time, developers have wanted to change the CVS code significantly to add new features, refactor the code, alter the operational model and improve developers' productivity. This has led to the phrase YACC: "Yet Another CVS Clone" (itself a play on the Unix command named, <code>[[yacc]]</code>, which stands for "yet another compiler compiler"). CVS replacement projects include [[CVSNT]] (first released 1998), [http://www.evscm.org/ EVS] (first released 2008), [[OpenCVS]] (not released as of 30 June 2010<ref>{{cite web|url=http://www.opencvs.org/|title=OpenCVS|publisher=OpenCVS|accessdate=June 30, 2010}}</ref>) and [[Subversion (software)|Subversion]]<ref>{{cite web|url=http://subversion.apache.org/faq.html#why|title=Subversion FAQ: Why does this project exist?|publisher=[[Subversion (software)|]]|accessdate=September 21, 2009}}</ref><ref>{{cite web|url=http://www.red-bean.com/sussman/svn-anti-fud.html|title=Dispelling Subversion FUD|publisher=Ben Collins-Sussman|accessdate=June 30, 2010}}</ref> (initially released in 2004<ref>Subversion released 23rd February 2004: and the CHANGELOG proof can be found [http://svn.collab.net/repos/svn/trunk/CHANGES here]</ref>) and numerous systems to support [[distributed revision control]].
* {{ cite book | author = David Thomas | author2 = Andrew Hunt | author-link2 = Andy Hunt (author) | title = Pragmatic Version Control Using CVS | publisher = The Pragmatic Programmers | year = 2003 | isbn = 0-9745140-0-4 | url = https://archive.org/details/pragmaticversion00thom | author-link = Dave Thomas (programmer) | url-access = registration }}
* {{ cite book | author = Jennifer Vesperman | title = Essential CVS | edition = 2e | publisher = O'Reilly | year = 2006 | isbn = 0-596-52703-9 }}
* {{ cite book | author = Per Cederqvist | title = Version Management with CVS | year = 2002 | publisher = Network Theory | isbn = 0-9541617-1-8 | url = http://www.network-theory.co.uk/docs/cvsmanual/ | display-authors = etal | access-date = 2009-11-25 | archive-url = https://web.archive.org/web/20140805142426/http://www.network-theory.co.uk/docs/cvsmanual/ | archive-date = 2014-08-05 | url-status = dead }}
* {{ cite book | author = Karl Franz Fogel | author2 = Moshe Bar | author-link2 = Moshe Bar (investor) | title = Open Source Development with CVS | year = 2003 | publisher = Paraglyph Press | isbn = 1-932111-81-6 | url = http://cvsbook.red-bean.com/ | access-date = 2002-02-05 | archive-url = https://web.archive.org/web/20140716125342/http://cvsbook.red-bean.com/ | archive-date = 2014-07-16 | url-status = dead }}
{{refend}}


== See also ==
== External links ==


* {{official|http://savannah.nongnu.org/projects/cvs}}
{{Portal|Free software}}
* [[StatCVS]], a program that generates graphical reports about CVS repositories.
* [[TortoiseCVS]], a ''shell-integrated'' [[CVSNT]] client for Windows (commonly used with CVS servers)<ref>{{Cite web
| last = Barrett
| first = Arthur
| title = Anonymous or Developer checkout with TortoiseCVS
| accessdate = 2010-07-10
| date = 2010-06-25
| url = http://drupal.org/node/22293
}}</ref><ref>{{Cite web
| last = Barrett
| first = Arthur
| title = TortoiseCVS instructions – sourceforge
| accessdate = 2010-07-10
| url = http://sourceforge.net/apps/trac/sourceforge/wiki/TortoiseCVS%20instructions
}}</ref>
* [[Bonsai CVS code management system]], a tool to report on files, directories, and branches under CVS management.
* [[Cervisia]], a KDE GUI frontend for CVS
* [[ViewVC]], a browser interface for CVS repositories
* [[OpenGrok]], a browser interface for CVS repositories
* [[CodeBeamer (software)]], a Collaborative Application Lifecycle Management solution with built-in CVS support.


{{Version control software}}
=== IDEs with support for CVS ===
{{Authority control}}
* [[Anjuta]]
* [[Aqua Data Studio]]
* [[Vim]]
** plugin: [http://www.vim.org/scripts/script.php?script_id=58 Menu for CVS-Versioncontrol]
* [[Emacs]]
* [[Dev-C++]]
* [[Eclipse (software)|Eclipse]]
** [[Aptana]]
* [[NetBeans]]
* [[IntelliJ IDEA]]
* [[wxDev-C++]]
* [[KDevelop]]
* [[Komodo IDE]]
* [[Xcode]]
* [[PHPEdit]]
* [[JDeveloper]]
* [[Oracle SQL Developer]]
* [[SlickEdit]]
* [[Wing IDE]] Professional
* [[Qt Creator]]

==References==
{{Reflist}}
{{Refbegin}}
* {{Cite book
| author = [[Dave Thomas (programmer)|David Thomas]]
| coauthors = [[Andy Hunt (author)|Andrew Hunt]]
| title = Pragmatic Version Control Using CVS
| publisher = The Pragmatic Programmers
| year = 2003
| isbn = 0-9745140-0-4
| url = http://www.pragprog.com/titles/vcc/pragmatic-version-control-using-cvs
}}
* {{Cite book
| author = Jennifer Vesperman
| title = Essential CVS
| edition = 2e
| publisher = O'Reilly
| year = 2006
| isbn = 0-596-52703-9
}}
* {{Cite book
| author = Per Cederqvist ''et al''
| title = Version Management with CVS
| isbn = 0-9541617-1-8
| url = http://www.network-theory.co.uk/docs/cvsmanual/
}}
* {{Cite book
| author = Karl Franz Fogel
| coauthors = [[Moshe Bar]]
| title = Open Source Development with CVS
| isbn = 1-932111-81-6
| url = http://cvsbook.red-bean.com/
}}
{{Refend}}

==External links==
* {{Official website|http://savannah.nongnu.org/projects/cvs}} (currently maintained by Derek Price)
* [http://www.cs.vu.nl/~dick/CVS.html Dick Grune's page about CVS]
* [http://www.brianberliner.com/2006/09/ask-brian-cvs-open-source-and-startups-today/ Interview with Brian Berliner: CVS creator]
* [http://www.linuxdevcenter.com/pub/a/linux/2002/01/03/cvs_intro.html Introduction to CVS]
* [http://tldp.org/REF/CVS-BestPractices/html/index.html CVS Best Practices] – A collection of practices for version control using CVS.
* [http://www.developingprogrammers.com/index.php/2005/11/24/cvs-and-subversion-combined-tutorial/ – Combined CVS and Subversion tutorial]
* [http://www.michael-amorose.com/articles/computers/cvs/6_1.html Michael Amorose's How To Set Up A CVS Server Page using Red Hat Linux]
* [http://ftp.gnu.org/non-gnu/cvs/source/feature/1.12.13/cederqvist-1.12.13.pdf Version Management with CVS] – manual for CVS 1.12.13, by Per Cederqvist et al.

{{Revision control software}}


[[Category:Concurrent Versions System| ]]
[[Category:1990 software]]
[[Category:1990 software]]
[[Category:Free software programmed in C]]
[[Category:Free software programmed in C]]
[[Category:Concurrent Versions System| ]]
[[Category:Free version control software]]
[[Category:Free revision control software]]
[[Category:Software using the GPL license]]
[[Category:Linux archivers and compression-related utilities]]
[[Category:Unix archivers and compression-related utilities]]

[[ar:نظام النسخ المتلاقية]]
[[bg:CVS]]
[[ca:CVS]]
[[cs:CVS]]
[[da:Concurrent Versions System]]
[[de:Concurrent Versions System]]
[[et:Concurrent Versions System]]
[[es:CVS]]
[[eo:CVS]]
[[eu:CVS]]
[[fr:Concurrent versions system]]
[[ko:CVS]]
[[it:Concurrent Versions System]]
[[nl:Concurrent Versions System]]
[[ja:CVS (バージョン管理システム)]]
[[no:Concurrent Versions System]]
[[pl:Concurrent Versions System]]
[[pt:CVS]]
[[ro:Concurrent Versions System]]
[[ru:CVS]]
[[sk:Concurrent Versions System]]
[[sv:Concurrent versions system]]
[[uk:Concurrent Versions System]]
[[vi:CVS]]
[[zh:協作版本系統]]

Latest revision as of 06:33, 5 September 2024

Concurrent Versions System
Developer(s)The CVS Team
Initial releaseNovember 19, 1990; 34 years ago (1990-11-19)
Stable release
1.11.23[1] / May 8, 2008; 16 years ago (2008-05-08)
Preview release
1.12.13[2] / September 28, 2005; 19 years ago (2005-09-28)
Repository
Written inC
Operating systemUnix-like, Windows
TypeRevision control
LicenseGPL-1.0-or-later[3]
Websitecvs.nongnu.org

Concurrent Versions System (CVS, or Concurrent Versioning System) is a version control system originally developed by Dick Grune in July 1986.[4]

Design

[edit]

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.[5] 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.[citation needed]

Operation

[edit]

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. To update is to acquire or merge the changes in the repository with the working copy.

CVS uses a client–server architecture: a server stores the current version(s) of a project and its history, and clients connect to the server in order to "check out" a complete copy of the project, work on this copy and then later "check in" their changes. CVS servers can allow "anonymous read access",[6] wherein clients may check out and compare versions with either a blank or simple published password (e.g., "anoncvs"); only the check-in of changes requires a personal account and password in these scenarios. Several developers may work on the same project concurrently, each one editing files within their own "working copy" of the project, and sending (or checking in) their modifications to the server. To avoid conflicts, the server only accepts changes made to the most recent version of a file. Developers are therefore expected to keep their working copy up-to-date by incorporating other people's changes on a regular basis. This task is mostly handled automatically by the CVS client, requiring manual intervention only when an edit conflict arises between a checked-in modification and the yet-unchecked local version of a file. Clients can also use the "update" command to bring their local copies up-to-date with the newest version on the server. Clients can also compare versions, request a complete history of changes, or check out a historical snapshot of the project (e.g.: based on a given date). If the check-in operation succeeds, then the version numbers of all files involved automatically increment, and the server writes a user-supplied description line, the date and the author's name to its log files. CVS can also run external, user-specified log processing scripts following each commit. These scripts are installed by an entry in CVS's loginfo file, which can trigger email notification or convert the log data into a Web-based format.

CVS can also maintain different "branches" of a project. For instance, a released version of the software project may form one branch, used for bug fixes, while a version under current development, with major changes and new features, can form a separate branch. CVS assumes that the majority of work takes place on the trunk, and that branches should generally be short-lived or historical. When used as designed, branches are easily managed and branch operations are efficient and fast.[7][8]

Portability

[edit]

The server software normally runs on Unix (although at least the CVSNT server also supports various flavors of Microsoft Windows), while CVS clients may run on any major operating system platform.

History

[edit]

Grune recalled:[9]

I created CVS to be able to cooperate with my students, Erik Baalbergen and Maarten Waage, on the ACK (Amsterdam Compiler Kit) C compiler. The three of us had vastly different schedules (one student was a steady 9-5 worker, the other was irregular, and I could work on the project only in the evenings). Their project ran from July 1984 to August 1985. CVS was initially called cmt, for the obvious reason that it allowed us to commit versions independently.

Grune publicly released the code on June 23, 1986.[10]

The code that eventually evolved into the current version of CVS started with Brian Berliner in April 1989, with later input from Jeff Polk and many other contributors. Brian Berliner wrote a paper introducing his improvements to the CVS program—which describes how the tool was extended and used internally by Prisma, a third-party developer working on the SunOS kernel, and was released for the benefit of the community under the GPL.[11] On November 19, 1990, CVS version 1.0 was submitted to the Free Software Foundation for development and distribution.[12]

The latest version was released on 8 May 2008.[13]

Adoption and successors

[edit]

In the world of open source software, the Concurrent Version System (CVS) has long been the tool of choice for version control. And rightly so. CVS itself is free software, and its non-restrictive modus operandi and support for networked operation—which allow dozens of geographically dispersed programmers to share their work—fits the collaborative nature of the open-source world very well. CVS and its semi-chaotic development model have become cornerstones of open-source.[14]

Over time, developers have created new version control systems based on CVS in order to add features, alter the operational model, and improve developers' productivity. CVS replacement projects include CVSNT and Subversion.[15][16]

See also

[edit]

Notes

[edit]
  1. ^ Stable CVS Version 1.11.23 Released!
  2. ^ CVS Feature Version 1.12.13 Released! * Security Update *
  3. ^ "Contents of /ccvs/README".
  4. ^ "CVS--Concurrent Versions System v1.12.12.1: Overview". Archived from the original on 15 April 2012. Retrieved 9 December 2011.
  5. ^ Stopak, Jacob (November 30, 2019). "The Evolution of Version Control System (VCS) Internals". Retrieved 22 September 2020.
  6. ^ Charles D. Cranor; Theo de Raadt (1999). "Opening The Source Repository With Anonymous CVS, USENIX 1999" (PDF). Archived (PDF) from the original on 2022-10-09.
  7. ^ Collins-Sussman, Ben; Greg Ward (September 2004). "Subversion Users: Re: Performance (Subversion vs. CVS)". subversion-users. Retrieved 2010-07-07.
  8. ^ West, Adrian (July 2004). "cvs branchtag performance fix". Archived from the original on 2009-08-03. Retrieved 2010-07-07.
  9. ^ "Concurrent Versions System CVS". dickgrune.com.
  10. ^ Dick Grune (July 3, 1986). "CVS, an RCS front-end (cvs)". Newsgroup: mod.sources. Usenet: 122@mirror.UUCP. Retrieved September 14, 2016.
  11. ^ "CVS II: Parallelizing Software Development - Berliner (ResearchIndex)". Archived from the original on September 9, 2004.
  12. ^ "[cvs] Contents of /ccvs/NEWS". cvs.savannah.gnu.org.
  13. ^ "Concurrent Versions System - News: Stable CVS Version 1.11.23 Released! [Savannah]". savannah.nongnu.org.
  14. ^ Ben Collins-Sussman, Version Control with Subversion For Subversion 1.1, 2005
  15. ^ "Subversion FAQ: Why does this project exist?". Subversion. Retrieved September 21, 2009.
  16. ^ "Dispelling Subversion FUD". Ben Collins-Sussman. Archived from the original on July 18, 2011. Retrieved June 30, 2010.

References

[edit]
[edit]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Concurrent_Versions_System&oldid=1244131268"