My Tech notes: CVS Short Notes And Useful Commands For Daily Usage
Subscribe

Unix Documentation

Free Online Unix Training Materials

Lists many links to free Unix training materials.

Pointers and Arrays Materials

Pointers and Arrays materials Explained for C beginners

C FAQ and General Questions C Interview Questions

Powered By

Free XML Skins for Blogger

Powered by Blogger

Thursday, January 22, 2009

CVS Short Notes And Useful Commands For Daily Usage

CVS Short Notes And Useful Commands For Daily Usage
Creating a directory tree from a number of files

When you begin using CVS, you will probably already have several projects that can be put under CVS control. In these cases the easiest way is to use the import command.

An example is probably the easiest way to explain how to use it. If the files you want to install in CVS reside in ‘wdir’, and you want them to appear in the repository as ‘$CVSROOT/yoyodyne/rdir’, you can do this:

$ cd wdir
$ cvs import -m "Imported sources" yoyodyne/rdir yoyo start

Unless you supply a log message with the ‘-m’ flag, CVS starts an editor and prompts for
a message. The string ‘yoyo’ is a vendor tag, and ‘start’ is a release tag. They may fill no purpose in this context, but since CVS requires them they must be present


Adding files and folder to CVS individually

To add a folder or file to CVS repository in some existing path, follow these steps.

For example, you want to create a folder “nuport” inside the path “firmware/projects”. First you should have local copy of that “firmware/projects”.

$ cd firmware/projects
$ mkdir nuport
$ cvs add nuport

Suppose you want to add a file to CVS which is inside the “nuport” directory then

$ cvs add filename.c
$ cvs ci –m “comment” filename.c

Remember that for adding files unless you do “cvs ci” the file will not be added completely to CVS.

NOTE: You can use “cvs ci” or “cvs commit”. Both commands are same.


Adding Binary Files

There are two issues with using CVS to store binary files. The first is that CVS by default converts line endings between the canonical form in which they are stored in the repository (linefeed only), and the form appropriate to the operating system in use on the client (for example, carriage return followed by line feed for Windows NT).

The second is that a binary file might happen to contain data which looks like a keyword so keyword expansion must be turned off. The ‘-kb’ option available with some CVS commands insures that neither line ending conversion nor keyword expansion will be done. Here is an example of how you add a binary file “testfile” using the ‘-kb’ flag:
$ cvs add -kb tesfile
$ cvs ci –m "First checkin" testfile


Setting custom versions

If you want to set the numeric revisions, the ‘-r’ option to CVS commit can do that. The ‘-r’ option implies the ‘-f’ option, in the sense that it causes the files to be committed even if they are not modified.

For example, to bring all your files up to revision 3.0 (including those that haven’t changed), you might invoke:

$ cvs commit -r 3.0

Note that the number you specify with ‘-r’ must be larger than any existing revision number. That is, if revision 3.0 exists, you cannot ‘CVS commit -r 1.3’. If you want to maintain several releases in parallel, you need to use a branch.


Check status of a file in working folder

For viewing the status of tags that the file has use :

$ cvs status –v backend.c

The states, as reported by the status command, are:

Up-to-date
The file is identical with the latest revision in the repository for the branch in use.
Locally Modified
You have edited the file, and not yet committed your changes.
Locally Added
You have added the file with add, and not yet committed your changes.
Locally Removed
You have removed the file with remove, and not yet committed your changes.
Needs Checkout
Someone else has committed a newer revision to the repository. The name is slightly misleading; you will ordinarily use update rather than checkout to get that newer revision.
Needs Patch
Like Needs Checkout, but the cvs server will send a patch rather than the entire file. Sending a patch or sending an entire file accomplishes the same thing.
Needs Merge
Someone else has committed a newer revision to the repository, and you have also made modifications to the file.
Unresolved Conflict
A file with the same name as this new file has been added to the repository from a second workspace. This file will need to be moved out of the way to allow an update to complete.
File had conflicts on merge
This is like Locally Modified, except that a previous update command gave a conflict. If you have not already done so, you need to resolve the conflict.
Unknown
CVS doesn’t know anything about this file. For example, you have created a new file and have not run add.


Giving tags

For setting up tags to files use the ‘cvs tag’ command. For example to tag a file called backend.c use the following:

$ cvs tag release-0-4 backend.c

The example in the previous section demonstrates one of the most common ways to choose which revisions to tag. Namely, running the CVS tag command without arguments causes CVS to select the revisions which are checked out in the current working directory.

For example, if the copy of ‘backend.c’ in working directory was checked out from revision 1.4, then CVS will tag revision 1.4. Note that the tag is applied immediately to revision 1.4 in the repository; tagging is not like modifying a file, or other operations in which one first modifies the working directory and then runs CVS commit to transfer that modification to the repository.

One potentially surprising aspect of the fact that CVS tag operates on the repository is that you are tagging the checked-in revisions, which may differ from locally modified files in your working directory. If you want to avoid doing this by mistake, specify the ‘-c’ option to CVS tag. If there are any locally modified files, CVS will abort with an error before it tags any files:

$ cvs tag -c rel-0-4
CVS tag: backend.c is locally modified
CVS [tag aborted]: correct the above errors first!


Use “cvs add” recursively to check-in code instead of “cvs import”

Suppose you want to check-in a large source which is inside a folder name “newfolder”.

To add the folder “newfolder” and it sub-directories into CVS, first do

$ find newfolder –type d –print | xargs cvs add

Then to add the files inside the “newfolder” and its subdirectories

$ find newfolder –name CVS –prune –o –type f –print | xargs cvs add

Then we have to commit these into CVS. The “cvs commit” is recursive, so we can give the following command

$ cvs commit –m “comment” newfolder/.

NOTE Please verify if everything has been checked in with these steps by checking out and compiling. I found some files (only which are last) didn’t get added while doing so, for kernel. This might be due to very large number of files in kernel source.


Important tips:

1) Use “cvs –help-commands” to get a list of supporting commands.
2) Use “cvs H ” to get help on the particular command. For example to get help on the command “commit” give as

$ cvs –H commit

No comments:

Post a Comment