cvsup is equal to
cvs -q up -dP)
edit/modify the file:
cvs di the_file.txt
if ok, then commit (make sure first all editors are closed!):
cvs ci the_file.txt
update-edit-view-diff-commit in one command using Spark's cvsed tool:
checkout whole ZON tree into sub-directory '.zon':
cvs co -d .zon zon:
checkout whole ZON tree into sub-directory 'zon2':
cvs co -d zon2 zon
faster, (but not garenteed clean) if you already have a checked out tree:
rm -rf .zon/build.*
cp -a .zon zon2
zcvs purge remove local modifications
checkout just specific sub-tree
to checkout zon/pkg/main into my_dir:
cvs co -d my_dir zon/pkg/main
check if we are updated with the server, without actually updating local
cvs -n update
update local files from the server
cvs update (better:
? unknown file - not in server, not in .cvsignore and not
scheduled for add
C (Conflict) Modified locally and on the server
U Updated on the server
P (Patched) Updated on the server (like U)
A scheduled for add
R scheduled for remove
cvs -q up -dP):
update a specific file
cvs update my_app.c
see differences between local file and server file
cvs diff my_app.c
g -d my_app.c):
see differences between two versions on the server
cvs diff -r tag-0_1_10 -r tag-0_1_12 my_app.c
commit - Save your changes to the cvs repository
How to commit
first, update the file to make sure you are working on the latest copy the
result of the update should be M on the file if the result is C then resolve
the conflicts manually
cvs update my_app.c
make sure that only the lines you want to be commited will be commited
cvs diff my_app.c
commit the file, and write a short description of the change, for the other users to understand at a glance
cvs commit my_app.c
make sure that following the commit, the command line responds with success message
adding a new file
cvs add my_app.c
cvs commit my_app.c
cvs ci my_app.c
removing a file
cvs remove my_app.c
cvs rm my_app.c
cvs ci my_app.c
moving a file
There is no native move. A move is done by removing and adding the file again. The first line of the log message should be 'MOVED old --> new' and the file names should include the full path (include the repository name).
mv .zon/doc/design/db_design.txt .zon/doc/requirements/db.txt
cvs rm .zon/doc/design/db_design.txt
cvs add .zon/doc/requirements/db.txt
cvs ci .zon/doc/requirements/db.txt .zon/doc/design/db_design.txt
MOVED zon/doc/design/db_design.txt --> zon/doc/requirements/db.txt
moved documetation from design to requirements dir.
checking status of a file
gets local version of the file, and the server version
cvs stat my_app.c
see the list of commits to a file
cvs log my_app.c
see part of log relating to specific tag/branch:
cvs log -N -rTAG my_app.c
see who when and where a line was added/modified
# this will detect when the call to
my_func() was added to the
cvs annotate my_app.c | grep "my_func()"
adding a lot of new files and directories:
DO NOT USE
cvs import! IT IS BROKEN.
See 'importing 3rd party code' section below.
Code commit message
All code commits must have informative commit massage. The message should contain the 'why' while the diff is the what.
Plan file commit message
Commit message for tasks file such as version_plan.txt can be just
updated when doing day-to-day updates. You can use
cvsed vp -M for doing that.
When doing doing non trivial changes, write meaningful commit massage such as
remove obsolete tasks.
to take out admin files
cvs checkout CVSROOT
to change an admin file
cvs commit cvswrappers
to checkout Zon V0.1.12 to zon_0_1_12 directory
cvs co -d zon_0_1_12 -r tag-0_1_12 wd
to add a binary:
cvs add -kb the_file
cvs commit the_file
to change an already committed ascii file to binary:
cvs admin -kb the_file
cvs update -A the_file
to change an already committed file that has -kk (or other keywords) to binary:
cvs up -kb the_file
cvs commit the_file
to branch a new version ('code freeze' for V1.0):
make sure everything is updated before tagging:
if the branch is from the main dev trunk, then: (this is the normal case)
cvs update -A -d
if the branch is from another branch, then:
cvs update -r branch-0_5 -d
add the tag to the repository:
cvs tag -c -b branch-1_0
cvs tag -c tag-1_0_0
now make the local copy use the tag:
cvs update -r branch-1_0
add a tag without a brach:
cvs tag -c tag-0_1_12
renaming a tag:
do not use tag use rtag, since tag does work on Attic files.
cvs rtag -r OLD_TAG NEW_TAG .zon/pkg/util
cvs rtag -d OLD_TAG .zon/pkg/util
renaming a branch tag:
On the repository itself perform the following:
for xx in `find . -type f` ; do rcs -nNEW_TAG:OLD_TAG $xx ; done
It should be done on the repository itself since "cvs admin -n" do not
perform the action on files in the Attic.
The last operation crated a new tag, now actually remove the old tag:
for xx in `find . -type f` ; do rcs -nOLD_TAG $xx ; done
search logs between dates in a specific branch into a file :
cvs log -Nd"01Jul2001<24Sep2001" -rbranch-10 > file_name
listing the changes from date until date:
cvs log -d "8 days ago<0 days ago" * > changes.txt
now edit the file changes.txt and search for the word "revision " (the space is important)
updating a branch for a specific date and time:
cvs up -r branch-3_3 -D"2003-10-21 12:30"
This will NOT put a sticky date (see cvs stat) but will update the files on the branch for the specified date and time.
importing changes from a modified tree to a tree just checked out (without committing)
assume the product is named zon, then:
~/zon.mod$ cvs diff -c > mod.diff
~/zon.mod$ cd ..
~$ cvs co -d zon.new zon
~$ cd zon.new
~/zon.new$ patch -p0 -d . < ../zon.mod/mod.diff
NEVER use a pipe when doing cvs ci:
wanted to commit a lot of newly added files so
~$ cvs -q up | grep "^A " > x
went over x and saw that those are the files that should be commited
~$ cat x | xargs cvs ci
this is WRONG since a pipe is used before xargs. this pipe messes cvs ci up, since cvs ci exects to use stdin for vi for log message editing. The CORRECT way to do it is hence:
~$ cvs ci 'cat x'
Listing all available modules on remote CVS for checkout (cvs co):
~$ cvs -d :pserver:anoncvs@anoncvs.FreeBSD.org:/home/ncvs co
this particular CVS has many ports which are not included by default into checkout of FreeBSD itself.
changing a file to binary:
cvs admin -kb drawing.bmp
changing a file back to regular text:
cvs admin -kkv listing.txt
canceling keyword substitution, but leaving crlf expantion:
cvs admin -ko file.cmd
Real Life Examples
checking out a new copy of the dev tree:
cvs co -d src.dev wd
checking out a new copy of the v4.00 tree:
cvs co -d zon_1_0 -r branch-1_0 zon
creating a tag WITHOUT a branch:
c:\src.dev> cvs tag -c tag-1_0_1
move a tag for a certain file from one version to another (force):
cvs tag -c -F beta_qa-intel_ixp-15oct01-100-rel
alternate more correct way to mark branches
tag the tree
cvs tag -c V_430
mark the branch point
cvs tag -c -b V_430_branch_yymmdd
or if you don't have a working copy
cvs rtag -c -b -r V_440 V_430_branch_yymmdd
creating V4.10 branch from dev tree:
make sure the files in dev are updated:
create the V4.10 branch:
cvs tag -c -b V_410
checkout the V4.10 to be able to work on it:
cvs co -d src.410 -r V_410 zon
No need to do before/after tags for merges!
Use branch+date if there is no tags available.
revisions between which to merge can be referenced tags (either textual or numeric), both static and dynamic (branches). one can merge between dates on a branch where no static tags are available by using the ":" operator.
example: to merge change which occured on branch-20 between the beginning of july and the end of september of 2001 we need to use:
cvs up -kk -j branch-20:02-Jul-01 -j branch-20:01-Oct-01
merging branch fixes with dev:
first, tag the merge location:
src.dev$ cvs up -d -r V_432
src.dev$ cvs tag -c V_432_MERGE_2MAY00_DEV
now, get back to the dev tree:
src.dev$ cvs up -A -d
add changes from branch (this example adds change from V_431 to V_432 to
the dev branch)
src.dev$ cvs up -d -kk -j V_431_MERGE_4APR00_DEV -j
now solve conflicts, and check the modification in the files.
you can take a look at the list of changed files again using:
src.dev$ cvs up
you can take a look at the list of changes inside the files using:
src.dev$ cvs diff
now commit the changes:
src.dev$ cvs commit
the remark should note the parameters of the diff. e.g.: "merge from V_431_MERGE_4APR00_DEV till V_432_MERGE_2MAY00_DEV into dev"
Releasing CVS Locks
If you get the following CVS lock:
cvs tag: [06:32:24] waiting for noam's lock in
then telnet cvs, find the locks, kill the processes locking and remove the locks. You do not need to be super-user on cvs to remove the locks.
fs$ cd /mnt/ram/cvslock/rg
fs$ find | grep "#cvs"
fs$ ps auxw | grep 14392
fs$ kill 14392
fs$ rm -rf os/linux-2.4/arch/m68k/sun3
If there are many locks, then you can do the following:
$ killall cvs
$ rm -rf /mnt/ram/cvslock/*
Notice that you will be killing all active CVS connections.
Creating a new branch or tag
Any tag/branch on CVS trees (e.g. rg, wd, uw, ut, project) should be documented in versions.csv. Virtually all tags are now created as soft-tags, which means committing them in versions.csv is all you need to do!!
Updating versions.csv: one of the following options:
- Creating a new official WinDriver branch (V_620) or tag (R_622) should be done according to <ilya - please point to the relevant document!>
- Creating a new official Spark branch (3.10.x branch or 188.8.131.52.x branch), or a new official Spark tag (3.10.4 or 184.108.40.206.6), should be done with zversion only! (see ).
- Spark development branches for BIG features: if this development branch will have a long life time, and many developers will be working on it, and a lot of Bugzilla and QA work will be done on the branch, then consider opening it as a customer branch (see above).
- any other tag/branch: use 'cvs tag' for initial creation in versions.csv. After running 'cvs tag', you can later return to versions.csv and chang any further settings as required - see explanations below.
Use of 'cvs tag':
(Example: tag-4_7_11 on branch-4_7)
$ cvs tag -v 4_7_11 -o branch-4_7 -m "product tag for 4.7.11"
-b for branches)
You can use the
-n option (of
cvs, so it comes
cvs) to prevent the changes from being committed to
-r DIRdefines the repository location for which the tag applies.
default: current location in tree (e.g. 'rg' when you're at the top of an RG CVS tree).
-bdesignates that this is a branch
-gmergeto - for branches only; designates the branch to which this branch will be auto-merged.
-ttime of tag - default: NOW. If you want an earlier time, put the time of the last commit that applies to the tag you're adding.
MAKE SURE TO USE UTC TIME (as it appears in 'CVS Search').
-hadds this as a hard-tag to CVS (come to yarony/derry first to explain why you need this!)
-fforce - allows moving of existing tags.
-c MSGspecifies the CVS commit message (default: same text given with -m)
-ddisplay in Bugzilla - should usually be used only with tags/branches added using jversion, or for ST tags.
rtagused instead of 'tag', if you want to do the tagging on CVS without having a checked-out repository.
Please look further at the
cvs usage message for a full
description of options to this command:
$ cvs | grep -A25 "cvs tag"
Explanation of versions.csv fields:
- symbol: name of symbol (tag or branch) as it appears in CVS
- version: name of version as known by Spark users
repository: location in CVS repository.
usually it is on top of one of our trees: ut, uw, wd, rg, etc. can be in lower points in trees for cases like vendor branches.
- isbranch: is the symbol a branch ?
- onsymbol: location point of symbol in CVS tree: either tag the the symbol was placed on, or parent branch.
- owner: owner of branch (responsible for code on it)
- creator: who actually created it
- tag_date: when was the tagging done - in UTC (GMT) time. for soft tags you can put the time of the latest commit that this branch/tag is based on.
- mergeto: for branches - what branch will this branch auto-merge into?
- description: textual description
- pl_owner: for customer branches/tags - the PL responsible for it. used by bugzilla to automatically assign R&D owner of bugs/enhancements, where this is applicable.
- qa_owner: QA owner. used in customer branches to automatically determine QA owner for bugzilla issues.
soft_tag: is this a soft tag/branch?
(should usually be 1, unless you have a good reason for using a hard-tag)
allow_manual_tag: should usually be
0, unless you have a VERY good reason for moving the tag on some files. usually it's better to just add a new tag in such cases.
allow_commit: allow commit in this symbol?
should always be
for branches, it allows to close the branch for committing. generally only active branches should have this field set to
- display_in_bugzilla: is this a tag/branch we want to display in the Bugzilla versions tree and accept it in the version fields?
Diff files and ignore CVS keywords
Use the following diff command to exclude CVS directories and CVS keywords:
diff -uNbNr --exclude="CVS" --exclude=".dist" -I