CVS : Java Glossary

CVS Environment Variables

Where CVS Squirrels Information

The Entries. file contains a snapshot of the timestamp and version of all the local files, in that directory as of the last update.

Repository. says where this directory belongs in the repository tree, e. g. com/mindprod/welcome where com is the project name.

Root. gives the url to login to the server.

CVSHOME/.cvspass contains the url to login and the encrypted password. CVSHOME is the designated CVSHOME directory, any directory you point the CVSHOME environment variable to. CVS also, of course, hides information most safely in the repository on the server. Anything lost can be regenerated from the server if you are willing to fool around. If this information is lost, you can always erase and checkout from scratch. CVS acts as a great backup system, just backing up just the changes and ignoring easily recreated files.

WinCVS also hides information in the settings directory "X:\Program Files\gnu\wincvs 1.2\settings\".

I have not been able to find the binary/text/ignore filter you define during import to fine tune it. Perhaps resides in the repository. Perhaps it exists only for the duration of the import.

Persuading CVS To Ignore Files

1. The one per-repository $CVSROOT/CVSROOT/cvsignore. file contains unqualified directory names, filenames and wildcards of directories and files to exclude from CVS processing. Usually you put one wildcard, directory or file per line. You can put more than one per line if you separate them with spaces, not commas. This is on the server that holds the repository.
2. The one per-user list in .cvsignore lives in your home directory. Don’t check your personal .cvsignore file into the repository! Note the dot comes at the beginning, not the end as for the one-per-repository cvsignore. file.
3. Any entries in the environment variable $CVSIGNORE.
4. Any -I options on the CVS command line.
5. As CVS traverses through your directories, the contents of any .cvsignore files it finds. The patterns found in those files are only valid for the directory that contains them, not for any sub-directories or parent directories. This is the form of cvsignore I have had most success with.

CVS Update Result Codes

CVS Aliases

cvs update -P myalias

CVS Error Messages

One puzzling error message you will get is:

Beautification

How many spaces do you indent per level? Do the {} match the enclosing or enclosed block or half way between? Do you always use {} after if? How much whitespace do you put around around operators + - * / () []?

You must agree on a common format, at least for the repository. Otherwise

• You will be plagued with false deltas — changes that are just changes in whitespace. This camouflages the real changes.
• People will be angry that other guys messed up their notion of perfect formatting.

You need beautifiers to fluff it back up again to whatever format each individual programmer likes best. You can’t very well demand he break a lifetime of habits particularly if every project has a different standard.

How CVS Works

There is a tiny cvs subdirectory inside every client directory under CVS control. In there is an Entries. file. The Entries. file contains a snapshot of the timestamp and version of all the local files that are also in the repository, in just that directory (not its children), as of the last update from the CVS server. It is:
not the current timestamp of the files.
not the date of the latest version of the files in the repository.
not the date of the file the last time you committed.
not the date you last updated the file.
but rather the date of your copy of the file the last time you did an update.

Once you understand that, everything makes sense.

When you do a checkout, CVS peppers the checkout directory with CVS directories. In the Entries. files in the directories are the timestamps of the files it gave you. The files and the Entries. file and dated with the timestamps the files were last checked in.

Let us say you don’t touch these files but came back in a week and asked for an update. In theory CVS could just send you the files all over again including any new files, but this would be time consuming. How does CVS know which files you already have up to date? If the dates of the files you have and the dates in the locally stored Entries. file match and that is the latest revision in the repository, there is no need to send that file again. I don’t know if CVS double checks this by computing and comparing file digest checksums. I do know it works by the client sending data to the server, not the reverse. CVS also seems to take just as along for an update no matter how recently you did one. I suspect it sends its entire list of file dates in each time, rather than just the ones that have changed since the last update.

The CVS server then sends any new and changed files. The local CVS client makes a note of the last-checked in date of the newly arrived files in the Entries file.

Now let us say that you modified a file but did not commit it yet. Then you requested an update. In this case any changes other people had merged to the file would be merged with your copy and the date this merging happened would be recorded in the Entries. file.

Then you decided to commit your file. The CVS Client and CVS server would get together and compare the version in the repository with your version and store the differerences in the repository. I am not sure just how clever they are about this to avoid having to transmit the entire file in either direction. The CVS client would record the timestamp this happened in the Entries. file.

CVS does not change the date on your copy of the file being committed. It might be a very old file.

What if you attempt to commit a file that has not really changed? You may have made a change and backed it out. You may have run some macro generator that produced the same results as last time. You may have used the touch utility. CVS won’t create a whole new revision in the repository for a null change. Perhaps to spank you for attempting a null commit without an update first, or perhaps just to warn you nothing happned, the CVS client does not update the Entries. file, so that the file still appears to be outstanding.

When you do an update, however, CVS will notice that the file has not really changed and will update the Entries. to match the date of the file on the on the local machine. It will have a different date than the file in the repository, but its contents are in sync, so is no longer considered commitable. It won’t change the date on your local file to match the repository’s. It records the date of the local file of the last check in the Entries. file, not the date of the check.

I have not experimented to discover just how cleverly CVS handles these false changes. It seems much faster than if it transmitted the entire file from server to client or vice versa only to discover the files were identical. I suspect they each compute a digest on the file, or parts of the file and compare those. If the lengths and digests match, odds are very good this was a false change.

In the Way

If you checkout a file and then change it there will be an entry for it in the Entries. file. If you just put the file there yourself there won’t. There won’t be any entries for brand new files you create either until they are added. However, if you copy a file in the directory rather than acquiring it through update and it already exists in the repository, CVS can detect that. It can treat all three differently.

CVS is protecting you from thinking you are creating a new file, but which already exists in the repository. CVS insists on putting the original copy of the repository file in your directory for you and creating the entry for it. You can then change it all you like. You can add all the new files you like, so long as they don’t already exist in the repository. It does not matter that even if the file in the way exactly matches the one in the respository.

The bottom line is, you have to checkout everything to an empty directory. The rule is just before adding files, do an update to make sure there are entries matching all the files in the respository.

Authentication

Alternatives

Grumbling

Another problem is moving files around or renaming them. To CVS these have to be handled as creations of entirely new files and deletions of old ones. It does not track the renaming history.

CVS merging of changes by two different programmers is not very bright. It is befuddled by white space or method reordering. You might want to look at the competition BitKeeper or Subversion. If you want to learn about how version control will by handled in future see dynamic version control.

Subversion fixes many of the infuriating CVS problems e.g.

• Subversion versions not only file contents and file existence, but also directories, copies and renames. This means you can delete and restore directories. You don’t have to keep dead empty directories around forever as in CVS. It also means that Subversion keeps track of the history of the renaming of a file. In CVS renaming looks like the deletion and creation of a new file with no record of the connection.
• No part of a commit takes effect until the entire commit has succeeded. Revision numbers are per-commit, not per-file. This especially important with flaky dial up connections.