The question of when to do an update is a complicated one. For sure you should update before working on any code and before checking any code in. This is to make sure you have the newest copy of the code before you begin work, and to make sure you have the newest copy of the code before you check your modified code back in (in case anyone modified the same code you're working on, or just to check that your new code works with the code in CVS, if anyone changed anything else)

To update, simple be in the module's directory on your local machine, and type:

cvs update -dP

The -d looks for new directories and the -P looks for deleted directories. This will give you output on the status of the files in the tree:

• U/P represents files that were updated locally from changes on the CVS server.
• M represents files that have been modified locally, and will need to be committed to the CVS repository.
• C indicates a conflict, and you may be required to fix it manually.
• ? indicates a file that CVS doesn't know about, and it may be a file that is built temporarily during compilation, or one that you need to add to CVS.

If you need to add files to the repository, issue the following command:

cvs add filename

After this, you will need to commit the file in order to permanently add it to CVS.

If you are sure you want to delete a file from the CVS repository, type:

cvs delete filename

After this, you will need to commit the file in order to permanently delete it from CVS (seems odd doesn't it???)

Once you are done working on a file (or group of files), or have added or deleted files, you will need to "commit" in order to put your changes on the CVS server. It is ALWAYS advised to do a "cvs update" before committing. If anyone else modified files that affect your code, this will give you a chance to make sure your copy works with the changes they made before checking yours in.

To commit a single file (good to do if you want very specific logs):

cvs commit -m "Comment" filename

To commit multiple files, simply list their names one after another.

If you just do:

cvs commit -m "Comment"

cvs will check in all the files in the current directory an below and log them with the comment you specified. Be careful about doing this because it can lead to very general, and not very helpful, logs.

When initially adding a binary file (e.g. an image), use the following command so that CVS knows it is a binary file:

cvs add -kb filename

If you've already added a file but didn't mark it as binary, type this:

cvs admin -kb filename

The revision numbers live a life of their own. They need not have anything at all to do with the release numbers of your software product. Depending on how you use CVS the revision numbers might change several times between two releases. As an example, some of the source files that make up RCS 5.6 have the following revision numbers:

 ci.c            5.21
 co.c            5.9
 ident.c         5.3
 rcs.c           5.12
 rcsbase.h       5.11
 rcsdiff.c       5.10
 rcsedit.c       5.11
 rcsfcmp.c       5.9
 rcsgen.c        5.10
 rcslex.c        5.11
 rcsmap.c        5.2
 rcsutil.c       5.10

You can use the tag command to give a symbolic name to a certain revision of a file. You can use the `-v' flag to the status command to see all tags that a file has, and which revision numbers they represent. Tag names must start with an uppercase or lowercase letter and can contain uppercase and lowercase letters, digits, `-', and `_'. The two tag names BASE and HEAD are reserved for use by CVS. It is expected that future names which are special to CVS will be specially named, for example by starting with `.', rather than being named analogously to BASE and HEAD, to avoid conflicts with actual tag names.

You'll want to choose some convention for naming tags, based on information such as the name of the program and the version number of the release. For example, one might take the name of the program, immediately followed by the version number with `.' changed to `-', so that CVS 1.9 would be tagged with the name cvs1-9. If you choose a consistent convention, then you won't constantly be guessing whether a tag is cvs-1-9 or cvs1_9 or what. You might even want to consider enforcing your convention in the taginfo file

The following example shows how you can add a tag to a file. The commands must be issued inside your working directory. That is, you should issue the command in the directory where `backend.c' resides.

 $ cvs tag rel-0-4 backend.c
 T backend.c
 $ cvs status -v backend.c
 ===================================================================
 File: backend.c         Status: Up-to-date
 
     Version:            1.4     Tue Dec  1 14:39:01 1992
     RCS Version:        1.4     /u/cvsroot/yoyodyne/tc/backend.c,v
     Sticky Tag:         (none)
     Sticky Date:        (none)
     Sticky Options:     (none)
 
     Existing Tags:
         rel-0-4                     (revision: 1.4)

There is seldom reason to tag a file in isolation. A more common use is to tag all the files that constitute a module with the same tag at strategic points in the development life-cycle, such as when a release is made.

 $ cvs tag rel-1-0 .
 cvs tag: Tagging .
 T Makefile
 T backend.c
 T driver.c
 T frontend.c
 T parser.c

(When you give CVS a directory as argument, it generally applies the operation to all the files in that directory, and (recursively), to any subdirectories that it may contain.

The checkout command has a flag, `-r', that lets you check out a certain revision of a module. This flag makes it easy to retrieve the sources that make up release 1.0 of the module `tc' at any time in the future:

 $ cvs checkout -r rel-1-0 tc

This is useful, for instance, if someone claims that there is a bug in that release, but you cannot find the bug in the current working copy. You can also check out a module as it was at any given date. When specifying `-r' to any of these commands, you will need beware of sticky tags. When you tag more than one file with the same tag you can think about the tag as "a curve drawn through a matrix of filename vs. revision number." Say we have 5 files with the following revisions:

  file1   file2   file3   file4   file5
 
  1.1     1.1     1.1     1.1  /--1.1*      <-*-  TAG
  1.2*-   1.2     1.2    -1.2*-
  1.3  \- 1.3*-   1.3   / 1.3
  1.4          \  1.4  /  1.4
                \-1.5*-   1.5
                  1.6

At some time in the past, the * versions were tagged. You can think of the tag as a handle attached to the curve drawn through the tagged revisions. When you pull on the handle, you get all the tagged revisions. Another way to look at it is that you "sight" through a set of revisions that is "flat" along the tagged revisions, like this:

   file1   file2   file3   file4   file5
 
                   1.1
                   1.2
           1.1     1.3                       _
   1.1     1.2     1.4     1.1              /
   1.2*----1.3*----1.5*----1.2*----1.1     (--- <--- Look here
   1.3             1.6     1.3              \_
   1.4                     1.4
                           1.5

Copyright © 1998-2014

Deepak Kumar Tala - All rights reserved

Do you have any Comment? mail me at:deepak@asic-world.com