Shell commands to get cvs up and going. Put these into .bashrc:
[email protected]:/opt/cvs export CVSROOT export CVS_RSH=ssh stty sane
cvs commands: how to check out/update, add to Vintela VAS software. Note that the command,
# cvs co
does not obliterate changes already made to files in the subdirectory, probably by reason of the later modification date. Here we arbitrarily decide to call the VAS head directory vas. Click here for a development “movement” script I use (to get around the VAS development tree quickly).
# mkdir vas (on path /home/russ/vas) # cvs co vintela-common (on path /home/russ/vintela-common) # cvs co -d vas VAS # cvs add filename # cvs commit filename
See also, Checking out (updating) a file....
Here’s how to see only those files you’ve modified when updating everything from the respository.
russ@taliesin:~/HEAD/VAS> cvs update 2> /dev/null | grep ^M M src/libs/vaslicense/Makefile.am M src/libs/vaslicense/licensing-test.c M src/vastool/info.c M src/vastool/vasypd.c
This works because the normal crap that is already up-to-date comes out on stderr while the other on stdout.
A file is first added, then committed, then checked out.
# cvs add filename # cvs commit filename
It’s acceptable to add more than one file or subdirectory name at a time.
However, new subdirectories do not need to be committed. You will get this message which you can ignore:
# cvs add directoryname # cvs commit directoryname # (no need to do this) cvs commit: Examining directoryname
Committing a change to a file (or just “committing a file”) is done thus:
# cvs commit filename
Merely updating the present tree; or update by erasing existing changes...
# cvs update # cvs update -c
If files that have been changed aren’t erased first, then an M prompt will appear during update next to that file’s name. This indicates a “merge” which, if changes made by other parties are anywhere near the changed parts of the file in your filesystem, may not be accurately done. A simple U prompt means that the file has been added by someone else and by this update is created new in your filesystem while a P means that someone else updated it and it replaces what you have in your filesystem.
russ@taliesin:~/vas/scripts> cvs update Password: cvs server: Updating . cvs server: Updating aix cvs server: Updating hpux cvs server: Updating install P install/install-product.sh.in # replaced M install/install.sh.in # merged (someone else changed it and so have I) cvs server: Updating linux cvs server: Updating macosx cvs server: Updating unix cvs server: Updating upm cvs server: Updating utils M utils/Makefile.am # merged (I meant to throw away my changes) U utils/migrate-2_6-3_0.sh.in # directory updated with new file cvs server: Updating yptools
A ? prompt indicates that a file was found that is not under the control of cvs nor is it in the .cvsignore file that tells cvs when to shut up about missing (ignored) files.
Intermediate and final files in the subdirectory, created by the action of making or building, must be noted so that cvs will not complain about them. For this purpose, a .cvsignore files is created in the subdirectory consisting simply of a list, one per line, of these files.
A quick check to see if anything has changed in the current subdirectory...
# cvs diff
Examining the log files for update owners and version numbers; displaying differences between the current and most recent update, and displaying differences between explicit, separate versions...
# cvs log filename # cvs diff filename # cvs diff -r version-number-1 -r version-number-2
However, be careful: the latest version (near the top of the resulting dump) of a file isn’t also the latest for a given branch, but only (probably) for the main trunk. Make certain you understand what you’re looking at. One way is to examine the status of the file, e.g.: main.c here...
# cvs status main.c Password: =========================================================================== File: main.c Status: Needs Patch Working revision: 1.161 Repository revision: 1.162 /opt/cvs/VAS/src/vascd-v3/main.c.v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none)
You can tell you’re checked out and working in a branch rather than the main trunk because the file, CVS/Tag, exists in the current subdirectory (if main trunk, this file doesn’t appear to exist) and typing it out produces something like:
# cat CVS/Tag TVAS_3_0_2_BRANCH
The foregoing is the future VAS product. Just prior to release lock-down, the tree is branched. (Compare the commands below with the original VAS check-out command.) Here, we create a new subdirectory for the branched code tree, then check out into it where we’ll make careful changes from now until SP1 is released.
# mkdir vas3sp1 # cvs co -d vas3sp1 -r VAS_3_0_1_SP1_BRANCH VAS
(Note: I’ve separated the arguments for this check-out command with white space and added bolding to make it all clearer.)
(And for VAS 2.6...)
# mkdir vas26 # cvs co -d vas26 -r VAS_2_6_SP5_BRANCH VAS
From this point on, there is nothing special that needs to be done for changes made in either tree (vas or vas3sp1, etc.) to be effective in that tree. Bug fixes and enhancements must be made separately in each tree to which they are to apply.
The code and other files in vintela-common changes only rarely and this subdirectory serves every checked-out version of VAS alike. Or used to. This changed at some point.
To branch a repository, use the following command, for example:
# cvs rtag -b -f -r VAS_3_3_1_BRANCH VAS_3_3_2_BRANCH VAS VAS-openssl VAS-docbook vintela-common vintela-docbook VGP VGPdocs VASbuild
...where VAS_3_3_1_BRANCH was the original codebase to be branched (as opposed to just plain HEAD) and VAS_3_3_2_BRANCH is the new designation. There are 8 repositories; none can be neglected.
Next, go into each branched repository to change the version in configure.in, look for “AC_INIT”, and the build number build-number.txt, zero out this number so it starts over:
The last one, version.txt, isn’t rev’d unless the VAS library has changed enough to warrant getting bumped.
Sometimes to fix a broken build that would be otherwise useless it is necessary to retag a later version of a file to get it included in the build. In this example, it was discovered that sshd.c had broken code that wouldn’t compile on Macintosh OSX. This was fixed and re-committed to cvs. Then this command was issued to get it into build 85:
russ@taliesin:~/VAS/src/preflight>: cvs tag -F VAS_3_3_0_85 sshd.c
If cvs bitches about checking in a previous version (let’s say you’re trying to cheat and do a hard, back-rev of a file by getting an older revision and committing that), go to subdirectory CVS, edit Entries, look for the file by name, and delete from the end of the line back to YYYY// where YYYY is the four-number year.
Alternatively, rename the file to something else, perform an update, delete the fresh copy and replace it with the edited file, then try again. Caution: ensure that no more recent version of the file has been committed.
Sometimes, both these exercises must be completed. This annoyance seems most frequent as soon as older versions of a file are got out of cvs. It’s no doubt something for which there is a right way to do it, but no one around here seems to know what that is.
...or so it’s called by some around here, but it’s pretty cool (and there are several here who use it despite the cat calls). The diff interface is absolutely dynamite and it’s all written in Java. Check it out...
The product site: http://www.smartcvs.com/.
(illustration of the diff interface)
If you’ve already got cvs going, you can simply install this thing and, once you launch it, choose Project->Project Manager->Add and then give it your existing project root. Then, after confirming this, go back and choose Project->Open. You will see all the stuff that’s currently different in your project directory tree than in the repository.
And, you don’t need a license, just use the “foundation” thingy when you first launch. Supported Linux, Windows and Mac OSX, requires Java 4.something or better.
It’s possible to create an ssh key on your host (as well as on remote hosts), to make it so you don’t have to keep typing in your cvs password:
# cd # ssh-keygen -t rsa (take all the defaults) # cd .ssh # cat id_rsa.pub > authorized_keys
This doesn’t work for me yet, but I’m still getting information from someone who knows. I’m informed that I need to put a file onto the cvs host (cvs.vintela.com), but which file and where?