export CVSROOT=/home/siddesh/cvs-repo
mkdir -p $CVSROOT
cvs init or (cvs -d $CVSROOT init)
# Above command is to set up your chosen directory as a CVS repository. 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. Projects are stored in subdirectories of the repository root directory, which is /home/siddesh/cvs-repoin our example.
2) Importing Projects
#Create your initial project directory structure, possibly in /tmp. Once the project is stored in CVS, this initial version can be removed.
mkdir ~/cvs-home #Create a temporary project directory
create ~/cvs-home/lilprogram/source.c #create temp file
#Once you have your initial structure, add any initial files you want. Change into the root directory of the project. Then, from within that directory, import the project with the command:
cd ~/cvs_home/lilprogram
cvs import -m "Test" lilprogram loci lilprogram_0_0
(or cvs -d repository_path import name_of_project vendor_tag release_tag)
Example 2: Importing a project
/tmp$ mkdir example
/tmp$ touch example/file1
/tmp$ touch example/file2
/tmp$ cd example
/tmp/example$ cvs -d /var/lib/cvsroot import example example_project ver_0-1
#In the repository, the imported project is stored as a collection of RCS files.
ls -l /home/siddesh/cvs_repo/
total 8
drwxrwxr-x 3 siddesh siddesh 4096 Feb 9 18:55 CVSROOT
drwxrwxr-x 3 siddesh siddesh 4096 Feb 9 19:03 lilprogram
ls -l /home/siddesh/cvs_repo/lilprogram/
total 8
drwxrwxr-x 2 siddesh siddesh 4096 Feb 9 18:53 Attic
-r--r--r-- 1 siddesh siddesh 1060 Feb 9 18:49 source.c,v
3) Accessing Remote Repositories
There are several ways to access a remote repository. One among them is ext method with the SSH protocol. The ext and SSH approach uses the ext repository access method, with an SSH client as the program that performs the connection.
Your first step,is to install SSH on the client machine. Make sure that the client-end SSH protocol matches the server's SSH protocol. Set up SSH keys or passwords and test the connection. Using SSH enables you to create a secure connection to the remote repository.
Next, if you're on a Unix or Linux system, set the CVS_RSH environment variable on your client machine to the name of your SSH program, usually ssh or ssh2.
On a remote machine, the repository path takes the form:
[:method:][[[user][:password]@]hostname[:[port]]]/path
Ex: :ext:cvs:/home/cvs
where "ext" is the method and "cvs" is the hostname.
4) Checkout
#CVS stores projects and files in a central repository, but you work from a working copy, called a sandbox , in your local directories. You create that sandbox with cvs checkout.
mkdir ~/cvs_home/client1
cd !$
cvs checkout lilprogram or (cvs -d repository_path checkout project_name)
Example 2:
$mkdir ~/cvs
$cd ~/cvs
$cvs -d /var/lib/cvsroot checkout example
cvs checkout: Updating example
U example/file1
U example/file2
#The checkout command puts a copy of the project's files and subdirectories into a directory named for the project, created in the current working directory. It also puts some administrative files of its own in a subdirectory of the project directory, called CVS.
#You can check out an individual file or subdirectory of a project by replacing project_name with the pathname to the file or directory, from the project's root directory. 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.
Example 3: Remote repository checkout
cvs -d :ext:cvs:/home/cvs checkout cvsbook
5) Commit & Update
#Once you've checked out project files into a sandbox, you can edit those files with your preferred editor. Changes are not synchronized with the repository until you run the cvs commit command. This command is best run from the root directory of your sandbox, and it must be run from within the sandbox.
vi source.c -> make changes
cvs update
cvs commit source.c (give description)
#If a revision in the repository is more recent than the revision the sandbox was based on, cvs commit fails. Use the cvs update command to merge the changed files; then run cvs commit again.
Ex: cvs update -d
#As a command option to the update command, -d downloads new directories and files.
#As the update command runs, it generates a list of files that are modified. To the immediate left of each filename, you will see a single uppercase letter. Those letters report the status of each file listed, and they have the following meanings:
U filename
Updated successfully. A newer version in the repository has replaced your sandbox version.
A filename
Marked for addition but not yet added to the repository (need to run a cvs commit).
R filename
Marked for removal but not yet removed from the repository (need to run a cvs commit).
M filename
Modified in your working directory. The file in the sandbox is more recent than the repository version or the sandbox and the repository both had changes that the system could safely merge into your sandbox copy (need to run a cvs commit).
C filename
There was a conflict between the repository copy and your copy. The conflict requires human intervention.
? filename
The file is in your working directory but not in the repository. CVS doesn't know what to do with it.
The A, R, and M codes mean that your sandbox contains changes that are not in the repository and it would be a good idea to run a cvs commit.
If CVS can't merge a modified file successfully with the copy in the repository, it announces the conflict in the output of cvs update.
CVS automatically merges files when the changes are on different lines. If a line in the repository copy is different from the corresponding line in the sandbox copy, CVS reports a conflict and creates a file with the two revisions of the line surrounded by special marks, as shown below
<<<<<<
= = = = = = =
This line came from the repository..
>>>>>>> 1.4
The contents of the original file are stored in .#file.revision in the file's working directory, and the results of the merge are stored as the original filename. Search for these marks in the file with the original name, edit the file, then commit the changed file to the repository.
6) Adding Files
To add a file to a project in the repository, first create the file in your sandbox. Be sure to consider your project's structure and place the file in the correct directory. Then, issue the following command from the sandbox directory containing the file:
cvs add filename
cvs add header.h; cvs commit
This command marks the new file for inclusion in the repository. Directories are added with the same command. Files within a directory can't be added until the directory itself is added. A file is only marked for addition when you run cvs add ; it is actually added to the repository when the next cvs commit is run. A directory is added to the repository immediately.
7) Removing Files
To remove a file from the repository, first remove the file from the sandbox directory; then run the following command from the sandbox directory that contained the file:
cvs remove filename
rm header.h; cvs remove header.h; cvs commit
The deletion does not take effect until the next cvs commit command is run; the file remains in the repository until then.
After thecvs commit is run, CVS doesn't remove the file entirely; it puts it in a special subdirectory in the repository called Attic . This saves the file history and enables the file to be returned to the repository later.
Use the -P flag to cvs checkout and cvs update to avoid empty directories in your sandbox.
8)Branching
cvs rtag -b lilprogram_0_1 lilprogram
cvs update -r lilprogram_0_1
cvs status source.c
9)Reverting to main branch
cvs update -A
cvs status source,c
10) Tag as label
edit source.c; cvs commit
cvs tag liltagl_01_0
cvs update -r lilprogram_0_1; cat source.c
11) Merging branches
edit source.c(in -0-1 branch); cvs commit source.c
cvs update -A; cvs update -j lilprogram_0_1; cvs commit source.c
14) export
cvs export -r lilprogram_0_1 lilprogram
15) annotate
cvs annotate source.c
2 comments:
Hi Sidhesh,
That was helpful for understanding the basics for a novice. We use CVS and normally do check in and check out and do not label while checking in. We have some quarterly release cycles and as a part of it would like to label the release, so that we can retrieve the code - based on the releases going forward. Could you throw some light on the best processes of doing this?
Hi siddhesh.. its really helpful artical... but i have got an problem with "cvs commit" command that i get error after running "cvs commit" command... [commit aborted]: 'root' is not allowed to commit files".. what should i do....
Post a Comment