Concurrent Versions System (CVS) Interview Questions And Answers

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.

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.

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

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.

To get a copy of the source for your own use, you can use "anonymous checkout". For a command line cvs client, make a new directory for the project, change to it, and tell CVS you exist with cvs -d:pserver:anonymous@jmri.cvs.sourceforge.net:/cvsroot/jmri login This "login" line is only needed once; after that, it is remembered on your local machine. You may be asked for a password. If so, just hit return, as the empty password will be accepted. You can then get a copy of the code with cvs -d:pserver:anonymous@jmri.cvs.sourceforge.net:/cvsroot/jmri co all If you're using a GUI-based client like WinCVS, pull down the "admin" menu and select "command line" to get a place to type these commands. On other computers, you can type them directly on the command line.

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

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

☛ 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.

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.

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.

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 {} ;

CVS is not setup as a separate daemon that listens continuously for a connection, it uses Inetd (Internet Daemon) to bind a connection request to the port used for CVS (2401) to the CVS server. The following commands should be executed as root. The file that supplies the information about which ports map to which services is /etc/services, edit this file and add the line:
☛ cvspserver 2401/tcp # CVS Pserver
☛ It may already be listed, in which case, leave it alone. Edit the file /etc/inetd.conf, add the line:
☛ cvspserver stream tcp nowait root /usr/local/bin/cvs cvs --allow-root=/home/jiansen/cvs pserver
☛ This causes inetd to start up a new cvs server and connect the server to the incoming connection request.
☛ killall -HUP inetd
This restarts inetd. Logon to some other machine and test the access using the cvs login command.

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.

CVSROOT environment variable, setenv CSVROOT (csh) or export CSVROOT= (bash)

If you have changed a file in CVS and want to commit your changes to the repository, type:
cvs commit filename

Checkout package or module:
cvs checkout module

To add a new file to the repository, first create the file in your checked out copy and then type:
cvs add -m'Brief description.' filename

Deleting a file involves similar steps. First delete the file out of your checked out copy, then use cvs remove to mark it as deleted, and then use cvs commit to commit the change:
rm filename
cvs remove filename
cvs commit filename

You can combine the first two steps by using:
cvs remove -f filename

If you want to get a report on what's changed between your copy and the repository, but don't want CVS do actually do anything, use the command:
cvs -n update

To see the differences (in diff format) between a file you've modified and the last committed revision in the repository, use:
cvs diff filename

(You can also give cvs diff multiple filenames or even whole directories and it will produce a series of diffs.) cvs diff takes the standard flags to specify what type of diff to produce, so:
cvs diff -u filename
will produce a unified context diff (the type that most people prefer).

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.

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.

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.

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.

There have been no official recent announcements indicating the project status:
☛ Active development of CVS has traditionally followed with new releases correlating directly with requests for new features or bug reports,
☛ The latest version was released 8 May 2008 (6 years, 10 months and 25 days ago).
☛ Since 2008 there have been some maintenance bugfixes in the CVS project's own CVS repository.
☛ There are no bugs or enhancements reported since the last code change that are complete (fulfill the requirement for a fix). There are a total of 9 reports, most of which are questions. Questions are typically answered quickly if asked on the mailing list.
☛ The info-cvs mailing list actively answer questions.
☛ Links on the official CVS page that point to the external web site ximbiot.com, such as 'Current Events,' are dead, as is the CVS.
☛ Archived information is available using new links.
☛ The last message in the Cvs-Announce mailing list was posted on 8 May 2008.
☛ The last code checkin to the CVS code repository occurred on 30 March 2011.

There are some useful commands that are being used very often. They are:
☛ cvs checkout
☛ cvs update
☛ cvs add
☛ cvs remove
☛ cvs commit

We can use two major techniques to handle the collisions. They are open addressing and separate chaining. In open addressing, data items that hash to a full array cell are placed in another cell in the array. In separate chaining, each array element consist of a linked list. All data items hashing to a given array index are inserted in that list.

The major advantage of a hash table is its speed. Because the hash function is to take a range of key values and transform them into index values in such a way that the key values are distributed randomly across all the indices of a hash table.

NFS stands for Network File System. NFS enables file systems physically residing on one computer system to be used by other computers in the network, appearing to users on the remote host as just another local disk.

Concurrent Versions System (also known as Concurrent Versioning System or CVS) is a free software revision control system -that is, it is a program that is open for use to the public that manages changes to documents, programs, and other information stored in computer files). It allows multiple developers to collaborate.
Subversion (also known as SVN) is a version control system used to maintain the current and preceding versions of files (like source code, web pages, and documentation). It is a direct upgrade of CVS and its most compatible successor. It is also an open source technology and has been widely used in multiple projects -such as Apache Software Foundation, Free Pascal, MediaWiki, and Google code.
1. CVS allows multiple users to collaborate on the same project; Subversion maintains the current and preceding versions of files.
2. CVS allows users to check in on the same project and modify it; Subversion commits as true atomic operations.
3. CVS can maintain different branches of a project; Subversion uses parsable output.