Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
CVSINTRO(7)	   FreeBSD Miscellaneous Information Manual	   CVSINTRO(7)

     cvsintro -- introduction to Concurrent Versioning System

     Concurrent	Versions System	is a popular open source version control sys-
     tem.  Although it is mostly used to track changes to software source code
     for development teams, there are very few limitations to the kind of data
     that can be managed by the	system,	and it can be used for document
     archival purposes as well.

     This document provides an introduction to using OpenCVS to	manage reposi-
     tories.  It will first cover some of the aspects of using and managing
     CVS and, where appropriate, explain the main differences between OpenCVS
     and other distributions.

     One of the	most common uses of cvs(1) is to track changes to a collection
     of	source files (a	module)	contained within a certain, defined, location
     (a	repository).  This allows the user to keep a set of local sources in
     sync with a set of	remote sources.	 It also allows	the user to view in-
     formation about changes to	the repository (such as	what the exact change
     was, who made it, and when), to view and compare information about	dif-
     ferent versions of	a file,	and possibly to	make local changes to files.

     As	an example, we'll look at a user wishing to track source changes to
     the OpenBSD tree, maintaining a local (personal) copy of the source on
     their own machine.	 The user will have to decide:

     +o	 The CVS server	to use.	 There may be only one server or, for larger
	 projects, a number of mirror servers.

     +o	 Where the source module(s) will be kept on the	local machine.

     In	our example, the OpenBSD project, there	are a large number of servers
     to	choose from.  It's generally better to use a server that is geographi-
     cally closer since	this tends to be faster	and less of a strain for the
     master server.  Utilities such as ping(8) and traceroute(8) can be	used
     to	decide which host will be best to use.	Secondly, the local repository
     has to be stored somewhere.  OpenBSD uses /usr/src	as the default loca-
     tion for its source tree (the "src" module), but this is largely arbi-

     This example shows	how a user initially checks out	a copy of the source
     tree from local mirror

	   $ cd	/usr
	   $ cvs -d	checkout -P src

     In	this case it was first necessary to add	ourselves to the "wsrc"	group,
     since /usr/src is writable	only by	user "root" and/or group "wsrc".  The
     -d	option was necessary to	tell cvs(1) the	location of the	remote server.
     Note the ":/cvs" string appended to the server's address: the path	to the
     repository	must be	specified.  Finally the	checkout command was used to
     obtain a copy of the module "src".

     Note that the above example simply	checked	out OpenBSD-current: often
     different software	versions are available:	use an identifier (tag)	to
     specify which version to check out.

     Thereafter	the user is free to manipulate the source tree using the
     cvs(1) utility itself.  For example, the following	would update (sync)
     the local copy of "src" with the remote copy:

	   $ cd	/usr/src
	   $ cvs -d	update -Pd

     General users may wish to use cvs(1) simply to keep a copy	of sources up
     to	date with a development	tree; developers of software projects can also
     use cvs(1)	to make	their own changes to a set of remote source files, and
     to	view changes made by other software developers.

     See cvs(1)	for more information on	the different commands available.  See
     the entry for $HOME/.cvsrc	in cvs(5) for details on configuring cvs(1)

     Software developers may wish to use cvs(1)	to manage their	own software
     projects.	Here we	look at	an example usage: providing remote access to a
     small group of developers working on project "foo", located in
     /cvs/projects.  First of all a repository has to be created.  A reposi-
     tory is just the location of the group of files to	be managed.  Within
     the repository, files may be organised into collections of	files, called
     modules, which are	just logical groupings of files.

     In	our example, module "foo" is located at	/cvs/projects/foo on machine
     "".	 Therefore /cvs/projects is both the root directory
     ($CVSROOT)	of our repository and the name of our repository.

     If	a set of source	files already exist, possibly already under revision
     control, they can be added	to a repository	using the cvs(1) command
     import.  This is a	useful way of adding modules to	a pre-existing reposi-
     tory.  In our example we are starting from	scratch, so the	repository has
     to	be initialised using the init command:

	   # cd	/cvs/projects
	   # cvs -d /cvs/projects init

     This will create a	default	administrative directory, $CVSROOT/CVSROOT,
     filled with files concerned with the management of	the repository.

     Thereafter, access	will have to be	arranged for developers	participating
     in	the project.  This typically means providing SSH access	via sshd(8)
     for remote	access,	unless the development network is local.

     cvs(1), rcs(1), cvs(5), sshd(8)

     The OpenCVS project is a -licensedBSD rewrite of the original Concurrent
     Versioning	System written by Jean-Francois	Brousseau.  The	original CVS
     code was written in large parts by	Dick Grune, Brian Berliner, and	Jeff

     Jean-Francois Brousseau

     This CVS implementation does not fully conform to the GNU CVS version.
     In	some cases, this was done explicitly because GNU CVS has inconsisten-
     cies or ambiguous behaviour.  Some	things have also been left out or mod-
     ified to enhance the overall security of the system.

     Among other things, support for the pserver connection mechanism has been
     dropped because of	security issues	with the authentication	mechanism.

FreeBSD	13.0			August 14, 2013			  FreeBSD 13.0


Want to link to this manual page? Use this URL:

home | help