Shell commands to get cvs up and going. Put these into
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.
[email protected]:~/HEAD/VAS> cvs update 2> /dev/null | grep ^M
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
# 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
[email protected]:~/vas/scripts> cvs update
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
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
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
# 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:
[email protected]:~/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
The product site:
(illustration of the diff interface)
If you’ve already got cvs going, you can simply install this
thing and, once you launch it, choose
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
# 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?