January 31, 2004

Checking the status of your files, using CVS

When I used CVS a few years ago, I remember a colleague writing a tremendous perl script that you could run from anywhere in the CVS source tree. It would let you know whether you had files that weren't in CVS, needed to be updated, or were going to be merged. It was quite a nice piece of perl code, which essentially parsed the output of cvs status, and the information it output was quite useful at the end of a long bug fixing or coding session ("hey, what files did I change again?"). However, it also needed to be maintained and documented, as well as explained to users.

The other day, I stumbled on something which works almost as well, but is part of CVS already: cvs -qn up. The q option tells CVS to be quiet, and not chat about all the directories that it sees. The n option tells CVS not to make any changes on the filesystem, but just tell you what changes it would have made. Here's some sample output:

[moore@localhost guide]$ cvs -qn up
? securityTechniques/NewStuff.rtf
M securityTechniques/InputValidation.rtf
M securityTechniques/SessionManagement.rtf
U securityTechniques/AuthenticationWorkingDraft.doc

M means that the file has been changed locally. ? means that the file exists on the locally, but not in the repository. U means that the file has changed in the repository, but not yet been updated locally. For more information on the output of update, look here.

Use this command and never lose track of the files in your CVS tree again.

Posted by moore at January 31, 2004 11:13 AM
Comments

Ah, yes, cvscheck. I remember it well. I also recall that it broke in some strange fashion depending on whether your CVS repository was "local", "ext" or "pserver". And we never figured out why.

I've kept cvscheck around and am still using it. I'll try out cvs update -qn. I still liked the human-readable output instead of the cryptic [MUCP?] letters, and the summary at the bottom (number of new/out of date/updated files).

Posted by: Tom Malaher at February 2, 2004 11:32 AM | Permalink
© Moore Consulting, 2003-2006