>Basic CVS commands used by BaBar
cvs -n update -dA [check how many files has been changed]
cvs diff -Dnow {file} [compare files with HEAD]
1) Isolate and examine one's changes before commit.
2) Make sure one does not accidentally compromise other's changes.
newrel -t [rel] [dir] [create a test release]
addpkg pkg [check out package from CVS]
cd pkg [cd to package]
cvs update -dA [before editing, update to HEAD]
[-d: getting new sub-directories if any]
emacs .. [making changes]
It's better updating to the head before making changes. Else you
may find yourself editing lines that has been revised sy someone
else.
If the HEAD version from CVS does not work anymore due to bugs introduced by others, following
the following procedure:
1. Fix <file> and test it in the local test release to prove that the patch works.
2. 'cvs update -dA <file>' to merge in other's patch if any.
3. Test again and make sure that the new version still works as much as possible.
4. Commit the code.
1) Compare files with HEAD:
cvs -n update -dA [list all files that have been modified]
U {file1} [there is new version in CVS, no diff needed]
M {file2} [there is new version in local folder, need diff]
C {file3} [there are new version in CVS and local folder, need diff]
cvs diff -Dnow {file} [examine the diff with HEAD]
One needs to compare files if the label is 'M' or 'C'.
Use 'cvs diff -Dnow' to compare local version with the HEAD. Look for changes that do not belong to you. If there is none, go to step 4).
If there is differences that do not belong to you, consider option 2) and 3).
2) If there is new version in CVS committed by another user. Type:
cvs update -dA [merge with HEAD version]
then go back to step 1) until only your changes remain in diff.
3) If your version is actually a copy from a previous version. Type:
mv {file} {file}.old [save your version]
cvs update -dA {file} [get a fresh copy]
emacs {file} [put your changes back]
then go back to step 1) until only your changes remain in diff.
4) Commit to CVS
cvs ci
Note: do not commit a copy back if you see any changes that do not
belong to you. When in doubt, always check out a fresh copy and
start over the editing session.
cvs -n update -dA [check how many files has been changed]
M {file1} [modified locally]
C {file2} [there is new version in CVS, need merging]
cvs update -dA [if local version is not head, update it]
Use 'cvs -n update -dA' to examine the status of your local folder. If
there is a files that is labelled 'C', it means this file will need
merging. You can go ahead and do the actual update or make a copy
before doing the merging.
cvs add {newfile} [add new files to local CVS database]
rm {oldfils} [remove from disk]
cvs rm {oldfiles} [remove from local database CVS/]
cvs ci [now actually commit changes to CVS]
After you made changes to a package, updated your local copy and commited your changes to the cvs repository you can tag this package version:
cvs update -dA [make sure it is up to date]
cvs tag {symbolic tag} [tag the package]
This will assign the symbolic tag to the repository version that corresponds to your local copy. The official symbolic tag in BaBar looks like the following:
V00-12-01. Official tags need to be made for any release build. For private
use between developers, "private" tags are often made. These usually consist
of the users initials plus the date, e.g. th030212 (or th030212a if more than
one is made per day). Private tags cannot be submitted for release builds,
an "official" tag will have to be made at that point. It is preferred that
all tags be either of the "official" form or the "private" form, and not
a mix of the two.
The preparation:
1) Create one "History" file for main directory and EACH
sub-directory if any.
2) Add "$Log: History,v $" to each History file.
Upon commit:
3) Add a carriage return to History file.
4) Type "cvs ci" or "cvs ci History file1 file2.." to
expand the key word with actual remarks of commit.