CVS

☛ CVSNT is the Windows OS version of cvs.

☛ From a SCM perpective, they share similarity in purpose, commands including syntax and functionality.

☛ Both are freeware.

☛ Installation is a breeze for anyone who has a working knowledge of *NIX and Windows.

☛ Both can be accessed through clients.

To allow all trusted CVS users access to the repository, we will create a cvsusers group. To do this add:

cvsusers:x:4901:jiansen,tom to /etc/group to create a cvsusers group, and add jiansen and tom to it. Note, 4901 is not special, it is any number not already in use as a group id or user id - I used it because it is the default port for a CVS pserver, which creates a nice link between the two.

cd /home/jiansen

find cvs/ -exec chgrp cvsusers {} ;

find $CVSROOT -type d -exec chmod g+s {} ;

People contribute updates to the JMRI code almost every week. Your local copy doesn't get these changes until you ask for them, so that you've got something stable to work with. If you have an existing copy of the code and want to update it to the most recent contents of CVS, the CVS command is: cvs -d:pserver:anonymous@jmri.cvs.sourceforge.net:/cvsroot/jmri -q update -dA

People contribute updates to the JMRI code almost every week. Your local copy doesn't get these changes until you ask for them, so that you've got something stable to work with. If you have an existing copy of the code and want to update it to the most recent contents of CVS, the CVS command is: cvs -d:pserver:anonymous@jmri.cvs.sourceforge.net:/cvsroot/jmri -q update -dA

As the common code changes, you might want to update your copy to contain the lastest version. To do that, use: cvs -q update Any changes will be merged into the files on your disk, and you should then be up-to-date with your own changes still present. The "-q" option removes a lot of informational messages as CVS enters the various directories in the project; the command still works if you omit it, but it will be harder to see any real error messages.

CVS works not by keeping track of multiple copies of source code files, but by maintaining a single copy and a record of all the changes. When a developer specifies a particular version, CVS can reconstruct that version from the recorded changes.

Many computers come with CVS installed, including Linux and MacOS X. If you're using Windows, you will need to install a CVS "client" program like WinCVS. A recent version can be downloaded from: http://prdownloads.sourceforge.net/cvsgui/WinCvs120.zip.

CVS uses another program, Revision Control System (RCS), to do the actual revision management that is, keeping the record of changes that goes with each source code file.

Suppose my project source code at /home/jiansen/project

1) mkdir /home/jiansen/cvs

2) export cvsroot=/home/jiansen/cvs

3) cvs init

4) cd /home/jiansen/project

4) cvs import -m "Initialising sources in CVS" project jiansen start

Now I am able to check out cvs project via cvs co project.

The problem management is related only when a configurable item having problem.

If you're using MacOS X, CVS may give you messages about ".DS_Store" files. These are used to keep track of window layouts, etc. To suppress these messages, just create a file in your home directory called ".cvsignore" and add a line of ".DS_Store" to it (no quotes). CVS will then ignore all .DS_Store files in all of your checked-out directory trees.

We can set our CVSROOT on a remote machine to the following.

Example:

let tom access my cvs export CVSROOT=:pserver:tom@mynode.ca:/home/jiansen/cvs

cvs login

Here password is the same as system password. We can setup specific password for 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. 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. Typically, the client and server connect over a 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 flavours of Microsoft Windows), while CVS clients may run on any major operating-system platform.

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 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 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. Storing files as binary is important in order to avoid corruption of binary files.