Notes on CVS

Notes on CVS

CVS Quick-start Guide
Installation CVS on Ubuntu

sudo -i
apt-get install cvs
Install the CVS server:

apt-get install cvsd
After you install cvs, you should install xinetd to start/stop the cvs server.
apt-get install xinetd
Building Your First Repository
mkdir /var/lib/cvsroot
cvs -d /var/lib/cvsroot init
chown -R cvsd:cvsd /var/lib/cvsroot
chmod g+srwx /var/lib/cvsroot
Once the initial repository is set up, you can configure xinetd to start the CVS server. You can copy the following lines to the /etc/xinetd.d/cvspserver file.
service cvspserver
port = 2401
socket_type = stream
protocol = tcp
user = root
wait = no
server = /usr/bin/cvs
server_args = -f --allow-root /var/lib/cvsroot pserver
disable = no
Once you have configured xinetd you can start the cvs server by running following command:
/etc/init.d/xinetd restart
You can confirm that the CVS server is running by issuing the following command:
sudo netstat -tap | grep cvs
When you run this command, you should see the following line or something similar:
tcp 0 0 *:cvspserver *:* LISTEN
Create a user and password
cvsd-passwd /var/lib/cvsroot +username
cvs -d :pserver:username:password@localhost:/var/lib/cvsroot login(logout)
cvs -d :pserver:username:password@localhost:/var/lib/cvsroot checkout .
To allow others to use the repository, create a Unix group for CVS users and chgrp the repository's root directory to that group. Set the directory's SGID bit, so that files created in the directory have the same group ID as the directory's group ID
CVS commands follow the format
cvs [cvs-options ] command [command -options ]
Setting up the repository produces a place to store projects and also adds the special CVSROOT directory. The CVSROOT directory contains configuration and metadata files.
Importing Projects
cvs -d repository_path import name_of_project vendor_tag release_tag. For most cases, you will not need to know about vendor tags and release tags. CVS requires them to be present, but you can just use the name of the project as the vendor tag and the current revision name as the release tag.
cvs -d /var/lib/cvsroot import example example_project ver_0-1
Accessing Remote Repositories
If the repository is on the same machine as the client, the repository path is simply the full path to the repository's root directory. On a remote machine, the repository path takes the form:
[:method :][[[ user][:password ]@]hostname [:[port]]]/path
The method is the protocol used to connect to the repository. To use SSH, use ext as the method.
Checking Out Files: cvs -d repository_path checkout project_name
CVS stores the repository path as part of the sandbox, so you should never again need to use -d repository_path in commands executed within that sandbox.
Committing Changes: cvs commit
Updating Sandboxes: cvs update -d
As a command option to the update command, -d downloads directories and files
Adding Files: cvs add filename
Removing Files: cvs remove filename
CVS does not remove directories from the repository, because doing so would break the change tracking. Use the -P flag to cvs checkout and cvs update to avoid empty directories in your sandbox.
CVS Command Syntax
cvs [cvs-options ] command [command -options ] [arguments ]

Here are the cvs-options that you will use most often:
-d repository_path
-n Does not change any files. This is useful when trying to figure out what a command does, without risking damage to the repository or the sandbox.
Repository Paths
[:method :][[[ user][:password ]@]hostname [:[port]]]/path
These are the access methods:
local Connect to the local machine.
ext Connect using an externally defined rsh or rsh-like connection method (such as ssh)
pserver Connect using the pserver (password server) connection method.
gserver Connect through the GSS-API (currently used for Kerberos 5.0).
fork Connect to a local machine as if it were a remote machine, using pipes for communication (useful if you are trying to diagnose problems).
Creating a Sandbox: checkout
-P Prunes empty directories.
-D date or -r revision or -r tag
Checks out a specific revision of the module based on date, revision, or tag.
Committing Changes to the Repository: commit [-m message]
Checking File Status: cvs [cvs-options ] status [command -options ] [filename ]

Updating the Sandbox Files from the Repository: cvs update -d
The -d option instructs CVS to download new directories from the repository to the
-P Avoid pulling down empty directories (not compatible with -d).
-C Overwrite files in the sandbox with copies from the repository.
Retrieving Past Revisions of a File
cvs update -r 1.2 src/wizzard.h
cvs update -j sandbox_revision -j previous_revision
Retrieving by date: cvs update -D 2002-09 -13 14:00 src/wizzard.h
Removing Files from the Repository: remove [command -options ] filename
-f Delete the file from the sandbox.
-R Perform recursive operation on all subdirectories as well as the current
directory (default).
Removing Directories
CVS doesn't include any mechanism for removing directories from a repository.
Any directory that contained files at a point in a project's history should be
retained so that earlier revisions of the project can be retrieved.
Moving Files or Directories
The recommended way to move a file is to use cvs remove followed by, cvs add, with messages that state where the file was moved from and to.
mv wizzard.h config.h
cvs remove wizzard.h
cvs add config.h
Releasing a Sandbox
cvs [cvs-options ] release [-d] directory
The only option to cvs release is -d, which deletes the sandbox after
checking it for uncommitted changes.
CVS recognizes keywords that can be included in any source file. CVS finds a keyword in a file it is checking out, it expands the keyword to provide metadata about the latest revision of the file. CVS keywords take the following form:
$Keyword $
The keywords are expanded when the file is checked out or updated.
These are the most commonly used keywords: Author, Date, Header, Name, Revision.
Header A header that contains information about the file, including the author, date and revision number, pathname of the RCS file, file status, and whether the file is locked.
Log Commit messages, dates, and authors, recorded in the file itself.
Binary Files and Wrappers
For binary files, CVS uses a different method of conflict resolution.
Specifying Default Command Options
If you find yourself regularly using the same options with a command, you can use the .cvsrc file to set default options and minimize your typing. If the .cvsrc file is in your home directory on your client machine, CVS will read the file, look for the CVS command you are currently running, and will run the command with the options specified for that command in the file.
The .cvsrc file format is one line per command. Start a line with the command you want to modify, followed by the options you want as the default. You can also specify default CVS options in the .cvsrc file, To do so, use cvs as the command.
A .cvsrc file
add -m "Part of the wizzard project"
update -P
checkout -P
cvs -q
Repository Management
Creating a Repository: cvs -d repository_root_directory init
The cvs init command sets up the directory as a CVS repository by creating the CVSROOT subdirectory and the initial files for that.
Deleting a Repository
A CVS repository that is no longer needed can be removed as you would remove a normal directory tree.
Creating a project with cvs add
To create a project with CVS commands other than cvs import, you need to check out a sandbox that contains only the repository root directory, create the new project root directory, and add that directory with cvs add.

To check out the repository root directory, use a period (.) as the project name. Use the -d name command option to give the sandbox a directory name. To avoid including subdirectories, use the -l command option to cvs checkout.
cvs -d cvs:/var/lib/cvs checkout -l -d cvsroot .
mkdir wizzard
cvs add wizzard
Creating a project by editing the repository
The second way to create a new project and bypass cvs import is to edit the repository directly.
Change directory into the repository root directory.
Use mkdir project_root_name to create the project root directory.
Distributing Files: checkout and update
Exporting Files

cvs export creates a release of the project's files that is suitable for publication.
cvs export does not create any CVS subdirectories or CVS administrative files.
cvs export requires that you use a date or tag command option. The -D now or -r HEAD options export the latest revisions of all files in a project.
cvs [cvs-options ] export [command -options ] project_name
The -d directory option provides a directory name for CVS to export the files to.
If you are exporting only one file from a subdirectory, CVS removes intermediate directories. Use -N with -d to prevent CVS from removing intermediate directories.
cvs -d cvs:/var/lib/cvs export -D now wizzard
Running Scripts
In the repository's CVSROOT directory, there are several scripting files that allow you to run scripts while a project is being committed, tagged, updated, or modified in other ways.
The common syntax is rule-based, one line per rule, and each rule consists of a pattern to be matched and an action to be taken.
The commitinfo File

The commitinfo file is processed before a file is committed and is usually used to enforce project standards for file format or content.
The loginfo File
The loginfo file is processed after files have been committed to the repository
The taginfo File
The taginfo file is processed before a file is tagged using either the tag or the rtag commands.
The cvs history Command: history [command -options ] [filenames …]

Pragmatic Version Control Using CVS
Essential CVS

Post a Comment


Java (159) Lucene-Solr (110) Interview (61) All (58) J2SE (53) Algorithm (45) Soft Skills (36) Eclipse (34) Code Example (31) Linux (24) JavaScript (23) Spring (22) Windows (22) Web Development (20) Nutch2 (18) Tools (18) Bugs (17) Debug (15) Defects (14) Text Mining (14) J2EE (13) Network (13) PowerShell (11) Troubleshooting (11) Chrome (9) Design (9) How to (9) Learning code (9) Performance (9) UIMA (9) html (9) Http Client (8) Maven (8) Problem Solving (8) Security (8) bat (8) blogger (8) Big Data (7) Continuous Integration (7) Google (7) Guava (7) JSON (7) ANT (6) Coding Skills (6) Database (6) Scala (6) Shell (6) css (6) Algorithm Series (5) Cache (5) Dynamic Languages (5) IDE (5) Lesson Learned (5) Programmer Skills (5) Tips (5) adsense (5) xml (5) AIX (4) Code Quality (4) GAE (4) Git (4) Good Programming Practices (4) Jackson (4) Memory Usage (4) Miscs (4) OpenNLP (4) Project Managment (4) Spark (4) System Design (4) Testing (4) ads (4) regular-expression (4) Android (3) Apache Spark (3) Become a Better You (3) Concurrency (3) Eclipse RCP (3) English (3) Happy Hacking (3) IBM (3) J2SE Knowledge Series (3) JAX-RS (3) Jetty (3) Restful Web Service (3) Script (3) regex (3) seo (3) .Net (2) Android Studio (2) Apache (2) Apache Procrun (2) Architecture (2) Batch (2) Bit Operation (2) Build (2) Building Scalable Web Sites (2) C# (2) C/C++ (2) CSV (2) Career (2) Cassandra (2) Distributed (2) Fiddler (2) Firefox (2) Google Drive (2) Gson (2) How to Interview (2) Html Parser (2) Http (2) Image Tools (2) JQuery (2) Jersey (2) LDAP (2) Life (2) Logging (2) Python (2) Software Issues (2) Storage (2) Text Search (2) xml parser (2) AOP (1) Application Design (1) AspectJ (1) Chrome DevTools (1) Cloud (1) Codility (1) Data Mining (1) Data Structure (1) ExceptionUtils (1) Exif (1) Feature Request (1) FindBugs (1) Greasemonkey (1) HTML5 (1) Httpd (1) I18N (1) IBM Java Thread Dump Analyzer (1) JDK Source Code (1) JDK8 (1) JMX (1) Lazy Developer (1) Mac (1) Machine Learning (1) Mobile (1) My Plan for 2010 (1) Netbeans (1) Notes (1) Operating System (1) Perl (1) Problems (1) Product Architecture (1) Programming Life (1) Quality (1) Redhat (1) Redis (1) Review (1) RxJava (1) Solutions logs (1) Team Management (1) Thread Dump Analyzer (1) Visualization (1) boilerpipe (1) htm (1) ongoing (1) procrun (1) rss (1)

Popular Posts