a2p
accept
access
acct
addftinfo
addr2line
adjtime
afmtodit
after
aio_cancel
aio_error
aio_read
aio_return
aio_suspend
aio_waitcomplete
aio_write
alias
aliases
alloc
anvil
append
apply
apropos
ar
array
as
asa
asn1parse
at
atq
atrm
attemptckalloc
attemptckrealloc
authlib
authtest
autopoint
awk
b64decode
b64encode
basename
batch
bc
bdes
bell
bg
bgerror
biff
big5
binary
bind
bindkey
bindtags
bindtextdomain
bio
bitmap
blowfish
bn
bootparams
bootptab
bounce
brandelf
break
breaksw
brk
bsdiff
bsdtar
bsnmpd
bspatch
bthost
btsockstat
buffer
builtin
builtins
bunzip2
button
byacc
bzcat
bzegrep
bzfgrep
bzgrep
bzip2
c2ph
c89
c99
ca
cal
calendar
canvas
cap_mkdb
case
cat
catch
catman
cc
cd
cdcontrol
chdir
checkbutton
checknr
chflags
chfn
chgrp
chio
chkey
chmod
chown
chpass
chroot
chsh
ci
ciphers
ckalloc
ckdist
ckfree
ckrealloc
cksum
cleanup
clear
clipboard
clock
clock_getres
clock_gettime
clock_settime
close
cmp
co
col
colcrt
colldef
colors
colrm
column
comm
command
compile_et
complete
compress
concat
config
connect
console
continue
core
courierlogger
couriertcpd
cp
cpan
cpio
cpp
creat
crl
crontab
crunchgen
crunchide
crypt
crypto
csh
csplit
ctags
ctm
ctm_dequeue
ctm_rmail
ctm_smail
cu
cursor
cursors
cut
cvs
date
dbiprof
dbiproxy
dc
dcgettext
dcngettext
dd
dde
default
defer
deliverquota
des
destroy
devfs
df
dgettext
dgst
dh
dhparam
dialog
diff
diff3
dig
dir
dirent
dirname
dirs
discard
disktab
dngettext
do
domainname
done
dprofpp
dsa
dsaparam
dtmfdecode
du
dup
dup2
eaccess
ec
ecdsa
echo
echotc
ecparam
ed
edit
editrc
ee
egrep
elf
elfdump
elif
else
enc
enc2xs
encoding
end
endif
endsw
engine
enigma
entry
env
envsubst
eof
eqn
err
errno
error
errstr
esac
ethers
euc
eui64
eval
event
evp
ex
exec
execve
exit
expand
export
exports
expr
extattr
extattr_delete_fd
extattr_delete_file
extattr_get_fd
extattr_get_file
extattr_set_fd
extattr_set_file
f77
false
famm
famx
fblocked
fbtab
fc
fchdir
fchflags
fchmod
fchown
fcntl
fconfigure
fcopy
fdescfs
fdformat
fdread
fdwrite
fetch
fg
fgrep
fhopen
fhstat
fhstatfs
fi
file
file2c
fileevent
filename
filetest
find
find2perl
finger
flex
flock
flush
fmt
focus
fold
font
fontedit
for
foreach
fork
format
forward
fpathconf
frame
from
fs
fstab
fstat
fstatfs
fsync
ftp
ftpchroot
ftpusers
ftruncate
futimes
g711conv
gb2312
gb18030
gbk
gcc
gcore
gcov
gdb
gencat
gendsa
genrsa
gensnmptree
getconf
getdents
getdirentries
getdtablesize
getegid
geteuid
getfacl
getfh
getfsstat
getgid
getgroups
getitimer
getlogin
getopt
getopts
getpeername
getpgid
getpgrp
getpid
getppid
getpriority
getresgid
getresuid
getrlimit
getrusage
gets
getsid
getsockname
getsockopt
gettext
gettextize
gettimeofday
gettytab
getuid
glob
global
gmake
goto
gperf
gprof
grab
grep
grid
grn
grodvi
groff
groff_font
groff_out
groff_tmac
grog
grolbp
grolj4
grops
grotty
group
groups
gunzip
gzcat
gzexe
gzip
h2ph
h2xs
hash
hashstat
hd
head
help2man
hesinfo
hexdump
history
host
hostname
hosts
hosts_access
hosts_options
hpftodit
http
hup
i386_get_ioperm
i386_get_ldt
i386_set_ioperm
i386_set_ldt
i386_vm86
iconv
id
ident
idprio
if
ifnames253
ifnames259
image
imapd
incr
indent
indxbib
info
infokey
inode
install
instmodsh
interp
intro
introduction
ioctl
ipcrm
ipcs
ipf
ipftest
ipnat
ippool
ipresend
issetugid
jail
jail_attach
jobid
jobs
join
jot
kbdcontrol
kbdmap
kcon
kdestroy
kdump
kenv
kevent
keycap
keylogin
keylogout
keymap
keysyms
kgdb
kill
killall
killpg
kinit
kldfind
kldfirstmod
kldload
kldnext
kldstat
kldsym
kldunload
klist
kpasswd
kqueue
kse
kse_create
kse_exit
kse_release
kse_switchin
kse_thr_interrupt
kse_wakeup
ktrace
label
labelframe
lam
lappend
last
lastcomm
lastlog
lchflags
lchmod
lchown
ld
ldap
ldapadd
ldapcompare
ldapdelete
ldapmodify
ldapmodrdn
ldappasswd
ldapsearch
ldapwhoami
ldd
leave
less
lesskey
lex
lgetfh
lhash
libnetcfg
library
limit
limits
lindex
link
linprocfs
linsert
lint
lio_listio
list
listbox
listen
lj4_font
lkbib
llength
lmtp
ln
load
loadfont
local
locale
locate
lock
lockf
log
logger
login
logins
logname
logout
look
lookbib
lorder
lower
lp
lpq
lpr
lprm
lptest
lrange
lreplace
ls
lsearch
lseek
lset
lsort
lstat
lsvfs
lutimes
lynx
m4
madvise
magic
mail
maildiracl
maildirkw
maildirmake
mailq
mailx
make
makeinfo
makewhatis
man
manpath
master
mc
mcedit
mcview
md2
md4
md5
mdc2
memory
menu
menubar
menubutton
merge
mesg
message
mincore
minherit
minigzip
mkdep
mkdir
mkfifo
mkimapdcert
mklocale
mknod
mkpop3dcert
mkstr
mktemp
mlock
mlockall
mmap
mmroff
modfind
modfnext
modnext
modstat
moduli
more
motd
mount
mprotect
mptable
msdos
msdosfs
msgattrib
msgcat
msgcmp
msgcomm
msgconv
msgen
msgexec
msgfilter
msgfmt
msggrep
msginit
msgmerge
msgs
msgunfmt
msguniq
mskanji
msql2mysql
msync
mt
munlock
munlockall
munmap
mv
myisamchk
myisamlog
myisampack
mysql
mysqlaccess
mysqladmin
mysqlbinlog
mysqlcheck
mysqld
mysqldump
mysqld_multi
mysqld_safe
mysqlhotcopy
mysqlimport
mysqlshow
mysql_config
mysql_fix_privilege_tables
mysql_zap
namespace
nanosleep
nawk
nc
ncal
ncplist
ncplogin
ncplogout
neqn
netconfig
netgroup
netid
netstat
networks
newaliases
newgrp
nex
nfsstat
nfssvc
ngettext
nice
nl
nm
nmount
nohup
nologin
notify
nroff
nseq
nslookup
ntp_adjtime
ntp_gettime
nvi
nview
objcopy
objdump
objformat
ocsp
od
onintr
open
openssl
opieaccess
opieinfo
opiekey
opiekeys
opiepasswd
option
options
oqmgr
pack
package
packagens
pagesize
palette
pam_auth
panedwindow
parray
passwd
paste
patch
pathchk
pathconf
pawd
pax
pbm
pcre
pcreapi
pcrebuild
pcrecallout
pcrecompat
pcrecpp
pcregrep
pcrematching
pcrepartial
pcrepattern
pcreperform
pcreposix
pcreprecompile
pcresample
pcretest
perl
perl56delta
perl58delta
perl561delta
perl570delta
perl571delta
perl572delta
perl573delta
perl581delta
perl582delta
perl583delta
perl584delta
perl585delta
perl586delta
perl587delta
perl588delta
perl5004delta
perl5005delta
perlaix
perlamiga
perlapi
perlapio
perlapollo
perlartistic
perlbeos
perlbook
perlboot
perlbot
perlbs2000
perlbug
perlcall
perlcc
perlce
perlcheat
perlclib
perlcn
perlcompile
perlcygwin
perldata
perldbmfilter
perldebguts
perldebtut
perldebug
perldelta
perldgux
perldiag
perldoc
perldos
perldsc
perlebcdic
perlembed
perlepoc
perlfaq
perlfaq1
perlfaq2
perlfaq3
perlfaq4
perlfaq5
perlfaq6
perlfaq7
perlfaq8
perlfaq9
perlfilter
perlfork
perlform
perlfreebsd
perlfunc
perlglossary
perlgpl
perlguts
perlhack
perlhist
perlhpux
perlhurd
perlintern
perlintro
perliol
perlipc
perlirix
perlivp
perljp
perlko
perllexwarn
perllinux
perllocale
perllol
perlmachten
perlmacos
perlmacosx
perlmint
perlmod
perlmodinstall
perlmodlib
perlmodstyle
perlmpeix
perlnetware
perlnewmod
perlnumber
perlobj
perlop
perlopenbsd
perlopentut
perlos2
perlos390
perlos400
perlothrtut
perlpacktut
perlplan9
perlpod
perlpodspec
perlport
perlqnx
perlre
perlref
perlreftut
perlrequick
perlreref
perlretut
perlrun
perlsec
perlsolaris
perlstyle
perlsub
perlsyn
perlthrtut
perltie
perltoc
perltodo
perltooc
perltoot
perltrap
perltru64
perltw
perlunicode
perluniintro
perlutil
perluts
perlvar
perlvmesa
perlvms
perlvos
perlwin32
perlxs
perlxstut
perror
pfbtops
pftp
pgrep
phones
photo
pic
pickup
piconv
pid
pipe
pkcs7
pkcs8
pkcs12
pkg_add
pkg_check
pkg_create
pkg_delete
pkg_info
pkg_sign
pkg_version
pkill
pl2pm
place
pod2html
pod2latex
pod2man
pod2text
pod2usage
podchecker
podselect
poll
popd
popup
posix_madvise
postalias
postcat
postconf
postdrop
postfix
postkick
postlock
postlog
postmap
postqueue
postsuper
pr
pread
preadv
printcap
printenv
printf
proc
procfs
profil
protocols
prove
proxymap
ps
psed
psroff
pstruct
ptrace
publickey
pushd
puts
pwd
pwrite
pwritev
qmgr
qmqpd
quota
quotactl
radiobutton
raise
rand
ranlib
rcp
rcs
rcsclean
rcsdiff
rcsfile
rcsfreeze
rcsintro
rcsmerge
read
readelf
readlink
readonly
readv
realpath
reboot
recv
recvfrom
recvmsg
red
ree
refer
regexp
registry
regsub
rehash
remote
rename
repeat
replace
req
reset
resolver
resource
return
rev
revoke
rfcomm_sppd
rfork
rhosts
ripemd
ripemd160
rlog
rlogin
rm
rmd160
rmdir
rpc
rpcgen
rs
rsa
rsautl
rsh
rtld
rtprio
rup
ruptime
rusers
rwall
rwho
s2p
safe
sasl
sasldblistusers2
saslpasswd2
sbrk
scache
scale
scan
sched
sched_getparam
sched_getscheduler
sched_get_priority_max
sched_get_priority_min
sched_rr_get_interval
sched_setparam
sched_setscheduler
sched_yield
scon
scp
script
scrollbar
sdiff
sed
seek
select
selection
semctl
semget
semop
send
sendbug
sendfile
sendmail
sendmsg
sendto
services
sess_id
set
setegid
setenv
seteuid
setfacl
setgid
setgroups
setitimer
setlogin
setpgid
setpgrp
setpriority
setregid
setresgid
setresuid
setreuid
setrlimit
setsid
setsockopt
settc
settimeofday
setty
setuid
setvar
sftp
sh
sha
sha1
sha256
shar
shells
shift
shmat
shmctl
shmdt
shmget
showq
shutdown
sigaction
sigaltstack
sigblock
sigmask
sigpause
sigpending
sigprocmask
sigreturn
sigsetmask
sigstack
sigsuspend
sigvec
sigwait
size
slapadd
slapcat
slapd
slapdn
slapindex
slappasswd
slaptest
sleep
slogin
slurpd
smbutil
smime
smtp
smtpd
socket
socketpair
sockstat
soelim
sort
source
spawn
speed
spinbox
spkac
splain
split
squid
squid_ldap_auth
squid_ldap_group
squid_unix_group
sscop
ssh
sshd_config
ssh_config
stab
startslip
stat
statfs
stop
string
strings
strip
stty
su
subst
sum
suspend
swapoff
swapon
switch
symlink
sync
sysarch
syscall
sysconftool
sysconftoolcheck
systat
s_client
s_server
s_time
tabs
tail
talk
tar
tbl
tclsh
tcltest
tclvars
tcopy
tcpdump
tcpslice
tcsh
tee
tell
telltc
telnet
term
termcap
terminfo
test
texindex
texinfo
text
textdomain
tfmtodit
tftp
then
threads
time
tip
tk
tkerror
tkvars
tkwait
tlsmgr
tmac
top
toplevel
touch
tput
tr
trace
trafshow
trap
troff
true
truncate
truss
tset
tsort
tty
ttys
type
tzfile
ui
ul
ulimit
umask
unalias
uname
uncomplete
uncompress
undelete
unexpand
unhash
unifdef
unifdefall
uniq
units
unknown
unlimit
unlink
unmount
unset
unsetenv
until
unvis
update
uplevel
uptime
upvar
usbhidaction
usbhidctl
users
utf8
utimes
utmp
utrace
uudecode
uuencode
uuidgen
vacation
variable
verify
version
vfork
vgrind
vgrindefs
vi
vidcontrol
vidfont
view
virtual
vis
vt220keys
vwait
w
wait
wait3
wait4
waitpid
wall
wc
wget
what
whatis
where
whereis
which
while
who
whoami
whois
window
winfo
wish
wm
write
writev
wtmp
x509
xargs
xgettext
xmlwf
xstr
xsubpp
yacc
yes
ypcat
ypchfn
ypchpass
ypchsh
ypmatch
yppasswd
ypwhich
yyfix
zcat
zcmp
zdiff
zegrep
zfgrep
zforce
zgrep
zmore
znew
_exit
__syscall
 
FreeBSD/Linux/UNIX General Commands Manual
Hypertext Man Pages
cvs
 
CVS(1)									CVS(1)



NAME
       cvs - Concurrent Versions System

SYNOPSIS
       cvs [ cvs_options ]
	      cvs_command [ command_options ] [ command_args ]

NOTE
       This  manpage is a summary of some of the features of cvs but it may no
       longer be kept up-to-date.  For more current  and  in-depth  documenta-
       tion, please consult the Cederqvist manual (via the info cvs command or
       otherwise, as described in the SEE ALSO section of this manpage).

DESCRIPTION
       CVS is a version control system, which allows you to keep old  versions
       of  files  (usually  source  code),  keep  a  log of who, when, and why
       changes occurred, etc., like RCS or SCCS.  Unlike the simpler  systems,
       CVS  does  not just operate on one file at a time or one directory at a
       time, but operates on hierarchical collections of directories  consist-
       ing  of	version controlled files.  CVS helps to manage releases and to
       control the concurrent editing of source files among multiple  authors.
       CVS  allows triggers to enable/log/control various operations and works
       well over a wide area network.

       cvs keeps a single copy of the master sources.  This copy is called the
       source  ``repository'';	it  contains  all  the	information  to permit
       extracting previous software releases at any time  based  on  either  a
       symbolic revision tag, or a date in the past.

ESSENTIAL COMMANDS
       cvs  provides a rich variety of commands (cvs_command in the Synopsis),
       each of which often has a wealth of options, to satisfy the many  needs
       of  source  management in distributed environments.  However, you don't
       have to master every detail to do useful work with cvs; in  fact,  five
       commands  are  sufficient to use (and contribute to) the source reposi-
       tory.

       cvs checkout modules...
	      A necessary preliminary for most cvs work: creates your  private
	      copy of the source for modules (named collections of source; you
	      can also use a path relative to  the  source  repository	here).
	      You  can	work  with  this copy without interfering with others'
	      work.  At least one subdirectory level is always created.

       cvs update
	      Execute this command from within your private  source  directory
	      when you wish to update your copies of source files from changes
	      that other developers have made to the source in the repository.

       cvs add file...
	      Use  this  command  to  enroll  new files in cvs records of your
	      working directory.  The files will be added  to  the  repository
	      the  next  time  you run `cvs commit'.  Note: You should use the
	      `cvs import' command to bootstrap new sources  into  the	source
	      repository.   `cvs add' is only used for new files to an already
	      checked-out module.

       cvs remove file...
	      Use this command (after erasing any  files  listed)  to  declare
	      that  you  wish  to  eliminate  files  from the repository.  The
	      removal does not affect others until you run `cvs commit'.

       cvs commit file...
	      Use this command when you wish to ``publish''  your  changes  to
	      other  developers,  by  incorporating them in the source reposi-
	      tory.

OPTIONS
       The cvs command line can include cvs_options, which apply to the  over-
       all  cvs program; a cvs_command, which specifies a particular action on
       the source repository; and  command_options  and  command_arguments  to
       fully specify what the cvs_command will do.

       Warning: you must be careful of precisely where you place options rela-
       tive to the cvs_command.  The same option  can  mean  different	things
       depending  on whether it is in the cvs_options position (to the left of
       a cvs command) or in the command_options position (to the  right  of  a
       cvs command).

       There  are only two situations where you may omit cvs_command: `cvs -H'
       or `cvs --help' elicits a list of available commands, and `cvs  -v'  or
       `cvs --version' displays version information on cvs itself.


CVS OPTIONS
       As of release 1.6, cvs supports GNU style long options as well as short
       options.  Only a few long options are currently	supported,  these  are
       listed  in brackets after the short options whose functions they dupli-
       cate.

       Use these options to control the overall cvs program:

       -H [ --help ]
	      Display usage information about the specified  cvs_command  (but
	      do  not  actually  execute the command).	If you don't specify a
	      command name, `cvs -H' displays a summary of  all  the  commands
	      available.

       -Q     Causes the command to be really quiet; the command will generate
	      output only for serious problems.

       -q     Causes the command to be somewhat quiet; informational messages,
	      such  as	reports  of recursion through subdirectories, are sup-
	      pressed.

       -b bindir
	      Use bindir as the directory where RCS programs are located  (CVS
	      1.9 and older).  Overrides the setting of the RCSBIN environment
	      variable.  This value should be specified as an  absolute  path-
	      name.

       -d CVS_root_directory
	      Use  CVS_root_directory  as  the	root directory pathname of the
	      master source repository.  Overrides the setting of the  CVSROOT
	      environment  variable.   This  value  should  be specified as an
	      absolute pathname.

       -e editor
	      Use editor to enter revision  log  information.	Overrides  the
	      setting  of  the CVSEDITOR, VISUAL, and EDITOR environment vari-
	      ables.

       -f     Do not read the cvs startup file (~/.cvsrc).

       -n     Do not change any files.	Attempt to  execute  the  cvs_command,
	      but  only  to issue reports; do not remove, update, or merge any
	      existing files, or create any new files.

       -t     Trace program execution; display messages showing the  steps  of
	      cvs activity.  Particularly useful with -n to explore the poten-
	      tial impact of an unfamiliar command.

       -r     Makes new working files read-only.  Same effect as if  the  CVS-
	      READ environment variable is set.

       -R     Turns  on  read-only  repository mode.  This allows one to check
	      out from a read-only  repository,  such  as  within  an  anoncvs
	      server,  or from a CDROM repository.  Same effect as if the CVS-
	      READONLYFS environment variable is set.  Using -R can also  con-
	      siderably speed up checkout's over NFS.

       -v [ --version ]
	      Displays version and copyright information for cvs.

       -w     Makes  new  working  files  read-write (default).  Overrides the
	      setting of the CVSREAD environment variable.

       -g     Forces group-write perms on working files.  This option is typi-
	      cally used when you have multiple users sharing a single checked
	      out source tree, allowing them to operate their  shells  with  a
	      less  dangerous  umask.  To use this feature, create a directory
	      to hold the checked-out source tree, set it to a private	group,
	      and  set	up  the  directory  such  that	files created under it
	      inherit the group id of the directory.   This  occurs  automati-
	      cally  with  FreeBSD.  With SysV you must typically set the SGID
	      bit on the directory.  The users who are to  share  the  checked
	      out tree must be placed in that group.  Note that the sharing of
	      a single checked-out source tree is very different  from	giving
	      several  users  access  to a common CVS repository.  Access to a
	      common CVS repository already maintains shared group-write perms
	      and does not require this option.

	      To  use the option transparently, simply place the line 'cvs -g'
	      in your ~/.cvsrc file.  Doing this is not recommended unless you
	      firewall	all  your  source  checkouts within a private group or
	      within a private mode 0700 directory.

       -x     Encrypt all communication between the client and the server.  As
	      of  this writing, this is only implemented when using a Kerberos
	      connection.

       -z compression-level
	      When transferring files across the network use  gzip  with  com-
	      pression	level  compression-level  to  compress and de-compress
	      data as it is transferred.  Requires the	presence  of  the  GNU
	      gzip  program  in  the  current  search path at both ends of the
	      link.

USAGE
       Except when requesting general help with `cvs -H', you must  specify  a
       cvs_command  to	cvs  to  select a specific release control function to
       perform.  Each cvs command accepts its own collection  of  options  and
       arguments.   However,  many  options  are available across several com-
       mands.  You can display a usage summary for each command by  specifying
       the -H option with the command.

CVS STARTUP FILE
       Normally,  when	CVS  starts up, it reads the .cvsrc file from the home
       directory of the user reading it.  This startup procedure can be turned
       off with the -f flag.

       The  .cvsrc  file lists CVS commands with a list of arguments, one com-
       mand per line.  For example, the following line in .cvsrc:

       diff -c

       will mean that the `cvs diff' command will  always  be  passed  the  -c
       option  in addition to any other options that are specified in the com-
       mand line (in this case it will have the effect	of  producing  context
       sensitive diffs for all executions of `cvs diff' ).

       Global  options	are specified using the cvs keyword.  For example, the
       following:

       cvs -q

       will mean that all `cvs' commands will behave as thought he  -q	global
       option had been supplied.

CVS COMMAND SUMMARY
       Here are brief descriptions of all the cvs commands:

       add    Add  a  new  file or directory to the repository, pending a `cvs
	      commit' on the same file.  Can only be done from within  sources
	      created  by  a  previous	`cvs  checkout'  invocation.  Use `cvs
	      import' to place whole new hierarchies of sources under cvs con-
	      trol.   (Does  not  directly  affect repository; changes working
	      directory.)

       admin  Execute control functions on the	source	repository.   (Changes
	      repository  directly;  uses  working  directory without changing
	      it.)

       checkout
	      Make a working directory of source files for editing.   (Creates
	      or changes working directory.)

       commit Apply to the source repository changes, additions, and deletions
	      from your working directory.  (Changes repository.)

       diff   Show differences between files in working directory  and	source
	      repository,  or  between	two  revisions	in  source repository.
	      (Does not change either repository or working directory.)

       export Prepare copies of a set of source files for shipment  off  site.
	      Differs from `cvs checkout' in that no cvs administrative direc-
	      tories are created (and therefore `cvs commit'  cannot  be  exe-
	      cuted  from  a directory prepared with `cvs export'), and a sym-
	      bolic tag must be specified.  (Does not change repository;  cre-
	      ates directory similar to working directories).

       history
	      Show reports on cvs commands that you or others have executed on
	      a particular file or directory in the source repository.	 (Does
	      not  change  repository or working directory.)  History logs are
	      kept only if enabled by creation of  the	`$CVSROOT/CVSROOT/his-
	      tory' file; see cvs(5).

       import Incorporate  a  set  of  updates	from  off-site into the source
	      repository, as a ``vendor branch''.  (Changes repository.)

       init   Initialize a repository by adding the CVSROOT  subdirectory  and
	      some  default  control  files. You must use this command or ini-
	      tialize the repository in some other way before you can use  it.

       log    Display log information.	(Does not change repository or working
	      directory.)

       rdiff  Prepare a collection of  diffs  as  a  patch  file  between  two
	      releases	in  the  repository.   (Does  not change repository or
	      working directory.)

       release
	      Cancel a `cvs checkout', abandoning any  changes.   (Can	delete
	      working directory; no effect on repository.)

       remove Remove  files from the source repository, pending a `cvs commit'
	      on the  same  files.   (Does  not  directly  affect  repository;
	      changes working directory.)

       rtag   Explicitly  specify  a  symbolic tag for particular revisions of
	      files in the source repository.  See also `cvs  tag'.   (Changes
	      repository  directly;  does not require or affect working direc-
	      tory.)

       status Show current status of files: latest version, version in working
	      directory,  whether working version has been edited and, option-
	      ally, symbolic tags in the RCS file.  (Does not  change  reposi-
	      tory or working directory.)

       tag    Specify a symbolic tag for files in the repository.  By default,
	      tags the revisions that were last synchronized with your working
	      directory.    (Changes  repository directly; uses working direc-
	      tory without changing it.)

       update Bring your working directory up to date with  changes  from  the
	      repository.  Merges are performed automatically when possible; a
	      warning is issued if manual resolution is required for conflict-
	      ing changes.  (Changes working directory; does not change repos-
	      itory.)

COMMON COMMAND OPTIONS
       This section describes the command_options that	are  available	across
       several	cvs  commands.	Not all commands support all of these options;
       each option is only supported for commands where it makes sense.   How-
       ever, when a command has one of these options you can count on the same
       meaning for the option as in other commands.  (Other  command  options,
       which are listed with the individual commands, may have different mean-
       ings from one cvs command to another.)  Warning: the history command is
       an  exception;  it  supports many options that conflict even with these
       standard options.

       -D date_spec
	      Use the most recent revision no later than date_spec  (a	single
	      argument,  date  description  specifying a date in the past).  A
	      wide variety of date formats are supported,  in  particular  ISO
	      ("1972-09-24  20:05")  or  Internet  ("24 Sep 1972 20:05").  The
	      date_spec is interpreted as being in the local timezone,	unless
	      a   specific   timezone  is  specified.	The  specification  is
	      ``sticky'' when you use it to make a private copy  of  a	source
	      file; that is, when you get a working file using -D, cvs records
	      the date you specified, so that  further	updates  in  the  same
	      directory will use the same date (unless you explicitly override
	      it; see the description of the update command).  -D is available
	      with  the  checkout,  diff,  history,  export,  rdiff, rtag, and
	      update commands.	Examples of valid date specifications include:
			1 month ago
			2 hours ago
			400000 seconds ago
			last year
			last Monday
			yesterday
			a fortnight ago
			3/31/92 10:00:07 PST
			January 23, 1987 10:05pm
			22:00 GMT

       -f     When  you specify a particular date or tag to cvs commands, they
	      normally ignore files that do not contain the tag  (or  did  not
	      exist on the date) that you specified.  Use the -f option if you
	      want files retrieved even when there is no match for the tag  or
	      date.   (The most recent version is used in this situation.)  -f
	      is available with these commands: checkout, export, rdiff, rtag,
	      and update.

       -k kflag
	      Alter  the  default  processing  of  keywords.  The -k option is
	      available with the  add,	checkout,  diff,  export,  rdiff,  and
	      update  commands.   Your	kflag specification is ``sticky'' when
	      you use it to create a private copy of a source file;  that  is,
	      when  you  use this option with the checkout or update commands,
	      cvs associates your selected kflag with the file, and  continues
	      to use it with future update commands on the same file until you
	      specify otherwise.

	      Some of the more useful kflags  are  -ko	and  -kb  (for	binary
	      files),  and -kv which is useful for an export where you wish to
	      retain keyword information after an import at some other site.

       -l     Local; run only in current working directory, rather than recur-
	      ring through subdirectories.   Available with the following com-
	      mands: checkout, commit, diff, export, remove, rdiff, rtag, sta-
	      tus, tag, and update.

       -n     Do  not  run any checkout/commit/tag/update program.  (A program
	      can be specified to run on each of these activities, in the mod-
	      ules  database;  this  option  bypasses it.)  Available with the
	      checkout, commit, export, and rtag commands.  Warning:  this  is
	      not the same as the overall `cvs -n' option, which you can spec-
	      ify to the left of a cvs command!

       -P     Prune (remove) directories that are empty after  being  updated,
	      on  checkout, or update.	Normally, an empty directory (one that
	      is void of revision-controlled files) is left alone.  Specifying
	      -P will cause these directories to be silently removed from your
	      checked-out sources.  This does not remove  the  directory  from
	      the repository, only from your checked out copy.	Note that this
	      option is implied by the	-r  or	-D  options  of  checkout  and
	      export.

       -T     Create/Update CVS/Template by copying it from the (local) repos-
	      itory.  This option is useful for developers maintaining a local
	      cvs  repository but committing to a remote repository.  By main-
	      taining CVS/Template the remote commits will still  be  able  to
	      bring  up  the  proper  template	in  the commit editor session.
	      Available with the checkout and update commands.

       -p     Pipe the files retrieved from the repository to standard output,
	      rather  than  writing  them in the current directory.  Available
	      with the checkout and update commands.

       -r tag Use the revision specified by the tag argument  instead  of  the
	      default  ``head''  revision.   As well as arbitrary tags defined
	      with the tag or rtag command, two special tags are always avail-
	      able:  `HEAD' refers to the most recent version available in the
	      repository, and `BASE' refers to the revision you  last  checked
	      out into the current working directory.

	      The  tag	specification  is  ``sticky'' when you use this option
	      with `cvs checkout' or `cvs update' to make your own copy  of  a
	      file:  cvs  remembers  the tag and continues to use it on future
	      update commands, until you specify otherwise.  tag can be either
	      a  symbolic  or  numeric	tag.   Specifying the -q global option
	      along with the -r command option is often  useful,  to  suppress
	      the  warning  messages  when  the  RCS file does not contain the
	      specified tag.  -r is available with the checkout, commit, diff,
	      history,	export,  rdiff,  rtag,	and update commands.  Warning:
	      this is not the same as the overall `cvs -r' option,  which  you
	      can specify to the left of a cvs command!

CVS COMMANDS
       Here (finally) are details on all the cvs commands and the options each
       accepts.  The summary lines at the top of  each	command's  description
       highlight three kinds of things:

	   Command Options and Arguments
		 Special options are described in detail below; common command
		 options may appear only in the summary line.

	   Working Directory, or Repository?
		 Some cvs commands require a  working  directory  to  operate;
		 some  require	a  repository.	Also, some commands change the
		 repository, some  change  the	working  directory,  and  some
		 change nothing.

	   Synonyms
		 Many  commands  have  synonyms,  which you may find easier to
		 remember (or type) than the principal name.


       add [-k kflag] [-m 'message'] files...
	      Requires: repository, working directory.
	      Changes: working directory.
	      Synonym: new
	      Use the add command to create a new file	or  directory  in  the
	      source  repository.  The files or directories specified with add
	      must already exist in the current  directory  (which  must  have
	      been  created  with  the	checkout command).  To add a whole new
	      directory hierarchy to the source repository (for example, files
	      received	from  a third-party vendor), use the `cvs import' com-
	      mand instead.

	      If the argument to `cvs add' refers to an  immediate  sub-direc-
	      tory,  the  directory  is  created  at  the correct place in the
	      source repository, and the necessary  cvs  administration  files
	      are created in your working directory.  If the directory already
	      exists in the source repository, `cvs  add'  still  creates  the
	      administration  files  in  your  version of the directory.  This
	      allows you to use `cvs add' to add  a  particular  directory  to
	      your private sources even if someone else created that directory
	      after your checkout of the sources.  You can do the following:

			example% mkdir new_directory
			example% cvs add new_directory
			example% cvs update new_directory

	      An alternate approach using `cvs update' might be:

			example% cvs update -d new_directory

	      (To add any available new directories to your working directory,
	      it's probably simpler to use `cvs checkout' or `cvs update -d'.)

	      The added files are not placed in the  source  repository  until
	      you use `cvs commit' to make the change permanent.  Doing a `cvs
	      add' on a file that was removed with the	`cvs  remove'  command
	      will  resurrect the file, if no `cvs commit' command intervened.

	      You will have the opportunity to specify a logging  message,  as
	      usual, when you use `cvs commit' to make the new file permanent.
	      If you'd like to have another logging  message  associated  with
	      just  creation  of the file (for example, to describe the file's
	      purpose), you can specify it with the `-m message' option to the
	      add command.

	      The  `-k	kflag' option specifies the default way that this file
	      will be checked out.  The `kflag' argument is stored in the  RCS
	      file  and  can be changed with `cvs admin'.  Specifying `-ko' is
	      useful for checking in binaries  that  shouldn't	have  keywords
	      expanded.

       admin [rcs-options] files...
	      Requires: repository, working directory.
	      Changes: repository.
	      Synonym: rcs
	      This is the cvs interface to assorted administrative facilities,
	      similar to rcs(1).  This command works recursively,  so  extreme
	      care should be used.

       checkout [options] modules...
	      Requires: repository.
	      Changes: working directory.
	      Synonyms: co, get
	      Make  a  working directory containing copies of the source files
	      specified by modules.  You must execute  `cvs  checkout'	before
	      using most of the other cvs commands, since most of them operate
	      on your working directory.

	      modules are either symbolic names  (themselves  defined  as  the
	      module  `modules' in the source repository; see cvs(5)) for some
	      collection of source directories and files, or paths to directo-
	      ries or files in the repository.

	      Depending  on  the modules you specify, checkout may recursively
	      create directories and populate them with the appropriate source
	      files.   You  can  then  edit  these  source  files  at any time
	      (regardless of whether other  software  developers  are  editing
	      their  own  copies  of  the sources); update them to include new
	      changes applied by others to the source  repository;  or	commit
	      your work as a permanent change to the repository.

	      Note that checkout is used to create directories.  The top-level
	      directory created is always added to the directory where	check-
	      out  is  invoked, and usually has the same name as the specified
	      module.  In the case of a module alias, the  created  sub-direc-
	      tory may have a different name, but you can be sure that it will
	      be a sub-directory, and that checkout  will  show  the  relative
	      path  leading  to each file as it is extracted into your private
	      work area (unless you specify the -Q global option).

	      Running `cvs checkout' on a directory that was already built  by
	      a  prior	checkout is also permitted, and has the same effect as
	      specifying the -d option to the update command described	below.

	      The  options  permitted with `cvs checkout' include the standard
	      command options -P, -f, -k kflag , -l, -n, -p, -r  tag,  and  -D
	      date.

	      In  addition to those, you can use these special command options
	      with checkout:

	      Use the -A option  to  reset  any  sticky  tags,	dates,	or  -k
	      options.	(If you get a working file using one of the -r, -D, or
	      -k options, cvs remembers the corresponding tag, date, or  kflag
	      and  continues  using it on future updates; use the -A option to
	      make cvs forget these specifications, and retrieve the  ``head''
	      version of the file).

	      The -j branch option merges the changes made between the result-
	      ing revision and the revision that it is based on (e.g., if  the
	      tag  refers to a branch, cvs will merge all changes made in that
	      branch into your working file).

	      With two -j options, cvs will merge in the changes  between  the
	      two respective revisions.  This can be used to ``remove'' a cer-
	      tain delta from your working file.

	      In addition, each -j option can contain on optional date	speci-
	      fication	which,	when  used with branches, can limit the chosen
	      revision to one within a specific date.	An  optional  date  is
	      specified by adding a colon (:) to the tag.  An example might be
	      what `cvs import' tells you to do when you  have	just  imported
	      sources that have conflicts with local changes:

			example% cvs checkout -jTAG:yesterday -jTAG module

	      Use the -N option with `-d dir' to avoid shortening module paths
	      in your working directory.   (Normally, cvs  shortens  paths  as
	      much as possible when you specify an explicit target directory.)

	      Use the -c option to copy the module file, sorted, to the  stan-
	      dard  output,  instead  of  creating  or	modifying any files or
	      directories in your working directory.

	      Use the -d dir option to create a directory called dir  for  the
	      working  files,  instead	of  using the module name.  Unless you
	      also use -N, the paths created under dir will  be  as  short  as
	      possible.

	      Use  the	-s  option  to	display  per-module status information
	      stored with the -s option within the modules file.

       commit [-lnR] [-m 'log_message' | -F file] [-r revision] [files...]
	      Requires: working directory, repository.
	      Changes: repository.
	      Synonym: ci
	      Use `cvs commit' when you want to incorporate changes from  your
	      working source files into the general source repository.

	      If  you  don't  specify  particular  files to commit, all of the
	      files in your working current directory are examined.  commit is
	      careful  to  change  in the repository only those files that you
	      have really changed.  By default (or if you  explicitly  specify
	      the  -R  option),  files in subdirectories are also examined and
	      committed if they have changed; you can use  the	-l  option  to
	      limit  commit  to the current directory only.  Sometimes you may
	      want to  force  a  file  to  be  committed  even	though	it  is
	      unchanged; this is achieved with the -f flag, which also has the
	      effect of disabling recursion (you can turn it back on  with  -R
	      of course).

	      commit  verifies that the selected files are up to date with the
	      current revisions in the source repository; it will notify  you,
	      and  exit without committing, if any of the specified files must
	      be made current first with `cvs update'.	commit does  not  call
	      the update command for you, but rather leaves that for you to do
	      when the time is right.

	      When all is well, an editor is invoked to allow you to  enter  a
	      log message that will be written to one or more logging programs
	      and placed in the source repository file.  You can instead spec-
	      ify the log message on the command line with the -m option, thus
	      suppressing the editor invocation, or use the -F option to spec-
	      ify that the argument file contains the log message.

	      The  -r option can be used to commit to a particular symbolic or
	      numeric revision.  For example, to bring all your  files	up  to
	      the revision ``3.0'' (including those that haven't changed), you
	      might do:

			example% cvs commit -r3.0

	      cvs will only allow you to commit to a revision that is  on  the
	      main  trunk  (a  revision  with a single dot).  However, you can
	      also commit to a branch revision (one that has an even number of
	      dots) with the -r option.  To create a branch revision, one typ-
	      ically use the -b option of the rtag  or	tag  commands.	 Then,
	      either  checkout	or  update can be used to base your sources on
	      the newly created  branch.   From  that  point  on,  all	commit
	      changes  made within these working sources will be automatically
	      added to a branch revision,  thereby  not  perturbing  main-line
	      development  in  any  way.   For example, if you had to create a
	      patch to the 1.2 version of the product,	even  though  the  2.0
	      version is already under development, you might do:

			example% cvs rtag -b -rFCS1_2 FCS1_2_Patch product_module
			example% cvs checkout -rFCS1_2_Patch product_module
			example% cd product_module
			[[ hack away ]]
			example% cvs commit

	      Say  you	have been working on some extremely experimental soft-
	      ware, based on whatever revision you happened to	checkout  last
	      week.   If others in your group would like to work on this soft-
	      ware with you, but without disturbing main-line development, you
	      could  commit  your  change  to  a  new branch.  Others can then
	      checkout your experimental stuff and utilize the full benefit of
	      cvs conflict resolution.	The scenario might look like:

			example% cvs tag -b EXPR1
			example% cvs update -rEXPR1
			[[ hack away ]]
			example% cvs commit

	      Others would simply do `cvs checkout -rEXPR1 whatever_module' to
	      work with you on the experimental change.

       diff [-kl] [format_options] [[-r rev1 | -D date1 | -j  rev1:date1]  [-r
       rev2 | -D date2 | -j rev2:date2]] [files...]
	      Requires: working directory, repository.
	      Changes: nothing.
	      You can compare your working files with revisions in the	source
	      repository, with the `cvs diff' command.	If you don't specify a
	      particular revision, your files are compared with the  revisions
	      they  were  based on.  You can also use the standard cvs command
	      option -r to specify a particular revision to compare your files
	      with.   Finally,	if  you  use -r twice, you can see differences
	      between two revisions in the repository.	You can  also  specify
	      -D  options  to  diff against a revision (on the head branch) in
	      the past, and you can also specify -j options to diff against  a
	      revision	relative  to  a branch tag in the past.  The -r and -D
	      and -j options can be mixed together with at  most  two  options
	      ever specified.

	      See `cvs --help diff' for a list of supported format_options.

	      If  you  don't  specify any files, diff will display differences
	      for all those files in the current directory (and its  subdirec-
	      tories,  unless you use the standard option -l) that differ from
	      the corresponding revision in the source repository (i.e.  files
	      that  you have changed), or that differ from the revision speci-
	      fied.

       export [-flNnQq] -r rev|-D date [-d dir] [-k kflag] module...
	      Requires: repository.
	      Changes: current directory.
	      This command is a variant of `cvs checkout';  use  it  when  you
	      want a copy of the source for module without the cvs administra-
	      tive directories.  For example, you might use  `cvs  export'  to
	      prepare  source  for  shipment  off-site.  This command requires
	      that you specify a date or tag (with -D or -r), so that you  can
	      count on reproducing the source you ship to others.

	      The  only  non-standard  options	are `-d dir' (write the source
	      into directory dir)  and	`-N'  (don't  shorten  module  paths).
	      These  have the same meanings as the same options in `cvs check-
	      out'.

	      The -kv option is useful when export is used.  This  causes  any
	      keywords	to  be expanded such that an import done at some other
	      site will not lose  the  keyword	revision  information.	 Other
	      kflags may be used with `cvs export' and are described in co(1).

       history [-report] [-flags] [-options args] [files...]
	      Requires: the file `$CVSROOT/CVSROOT/history'
	      Changes: nothing.
	      cvs keeps a history file that tracks each use of	the  checkout,
	      commit,  rtag,  update,  and release commands.  You can use `cvs
	      history' to display this information in various formats.

	      Warning: `cvs history' uses `-f', `-l', `-n', and `-p'  in  ways
	      that conflict with the descriptions in COMMON COMMAND OPTIONS.

	      Several  options	(shown	above as -report) control what kind of
	      report is generated:

	     -c  Report on each time commit was  used  (i.e.,  each  time  the
		 repository was modified).

	     -m module
		 Report  on a particular module.  (You can meaningfully use -m
		 more than once on the command line.)

	     -o  Report on checked-out modules.

	     -T  Report on all tags.

	     -x type
		 Extract a particular set of record types X from the cvs  his-
		 tory.	 The  types are indicated by single letters, which you
		 may specify in combination.  Certain commands have  a	single
		 record  type:	checkout  (type  `O'), release (type `F'), and
		 rtag (type `T').  One of four record types may result from an
		 update:  `W', when the working copy of a file is deleted dur-
		 ing update (because it was gone from  the  repository);  `U',
		 when a working file was copied from the repository; `G', when
		 a merge was necessary and it succeeded; and 'C', when a merge
		 was  necessary but collisions were detected (requiring manual
		 merging).  Finally, one of three record  types  results  from
		 commit:  `M',	when  a file was modified; `A', when a file is
		 first added; and `R', when a file is removed.

	     -e  Everything  (all  record  types);  equivalent	to  specifying
		 `-xMACFROGWUT'.

	     -z zone
		 Use time zone zone when outputting history records.  The zone
		 name LT stands for local  time;  numeric  offsets  stand  for
		 hours	and  minutes  ahead of UTC.  For example, +0530 stands
		 for 5 hours and 30 minutes ahead of (i.e. east of) UTC.

	    The options shown as -flags constrain the report without requiring
	    option arguments:

	     -a  Show data for all users (the default is to show data only for
		 the user executing `cvs history').

	     -l  Show last modification only.

	     -w  Show only the records for modifications done  from  the  same
		 working directory where `cvs history' is executing.

	    The  options  shown as -options args constrain the report based on
	    an argument:

	     -b str
		 Show data back to a  record  containing  the  string  str  in
		 either  the  module  name,  the  file name, or the repository
		 path.

	     -D date
		 Show data since date.

	     -p repository
		 Show data for a particular source repository (you can specify
		 several -p options on the same command line).

	     -r rev
		 Show records referring to revisions since the revision or tag
		 named rev appears in individual RCS files.  Each RCS file  is
		 searched for the revision or tag.

	     -t tag
		 Show  records	since  tag  tag  was last added to the history
		 file.	This differs from the -r flag above in that  it  reads
		 only the history file, not the RCS files, and is much faster.

	     -u name
		 Show records for user name.


       import [-options] repository vendortag releasetag...
	      Requires: Repository, source distribution directory.
	      Changes: repository.
	      Use `cvs import' to incorporate an  entire  source  distribution
	      from  an outside source (e.g., a source vendor) into your source
	      repository directory.  You can use this command both for initial
	      creation	of a repository, and for wholesale updates to the mod-
	      ule form the outside source.

	      The repository argument gives a directory name (or a path  to  a
	      directory) under the CVS root directory for repositories; if the
	      directory did not exist, import creates it.

	      When you use import for updates to source that has been modified
	      in your source repository (since a prior import), it will notify
	      you of any files that conflict in the two branches  of  develop-
	      ment;  use  `cvs	checkout  -j' to reconcile the differences, as
	      import instructs you to do.

	      By default, certain file names are ignored during `cvs  import':
	      names  associated  with CVS administration, or with other common
	      source control systems; common names  for  patch	files,	object
	      files,  archive  files, and editor backup files; and other names
	      that are usually artifacts of assorted utilities.  For an up  to
	      date  list  of ignored file names, see the Cederqvist manual (as
	      described in the SEE ALSO section of this manpage).

	      The outside source is saved in a first-level branch, by  default
	      `1.1.1'.	 Updates are leaves of this branch; for example, files
	      from the first imported collection of source  will  be  revision
	      `1.1.1.1',  then	files  from  the first imported update will be
	      revision `1.1.1.2', and so on.

	      At least three arguments are required.  repository is needed  to
	      identify	the  collection of source.  vendortag is a tag for the
	      entire branch (e.g., for `1.1.1').  You  must  also  specify  at
	      least one releasetag to identify the files at the leaves created
	      each time you execute `cvs import'.

	      One of the standard cvs command options is  available:  -m  mes-
	      sage.   If  you  do  not specify a logging message with -m, your
	      editor is invoked (as with commit) to allow you to enter one.

	      There are three additional special options.

	      Use `-d' to specify that each file's time of  last  modification
	      should be used for the checkin date and time.

	      Use  `-b	branch'  to  specify  a  first-level branch other than
	      `1.1.1'.

	      Use `-I name' to specify file names that should be ignored  dur-
	      ing  import.   You  can  use  this  option repeatedly.  To avoid
	      ignoring any files at all (even those ignored by default), spec-
	      ify `-I !'.

       log [-l] rlog-options [files...]
	      Requires: repository, working directory.
	      Changes: nothing.
	      Synonym: rlog
	      Display  log  information  for  files.   Among  the  more useful
	      options are -h to display only the header (including tag defini-
	      tions,  but omitting most of the full log); -r to select logs on
	      particular revisions or ranges of revisions; and	-d  to	select
	      particular  dates or date ranges.  See rlog(1) for full explana-
	      tions.  This command is recursive  by  default,  unless  the  -l
	      option is specified.

       rdiff [-flags] [-V vn] [-r t|-D d [-r t2|-D d2]] modules...
	      Requires: repository.
	      Changes: nothing.
	      Synonym: patch
	      Builds  a  Larry Wall format patch(1) file between two releases,
	      that can be fed directly into the patch program to bring an  old
	      release  up-to-date  with  the new release.  (This is one of the
	      few cvs commands that operates directly from the repository, and
	      doesn't  require	a prior checkout.)  The diff output is sent to
	      the standard output device.  You can specify (using the standard
	      -r  and  -D  options) any combination of one or two revisions or
	      dates.  If only one revision or date  is	specified,  the  patch
	      file  reflects differences between that revision or date and the
	      current ``head'' revisions in the RCS file.

	      Note that if the software release affected is contained in  more
	      than  one  directory, then it may be necessary to specify the -p
	      option to the patch command when patching the  old  sources,  so
	      that  patch  is able to find the files that are located in other
	      directories.

	      The standard option flags -f, and -l  are  available  with  this
	      command.	There are also several special option flags:

	      If you use the -s option, no patch output is produced.  Instead,
	      a summary of the changed or added files between the two releases
	      is sent to the standard output device.  This is useful for find-
	      ing out, for example, which files have changed between two dates
	      or revisions.

	      If  you  use  the  -t option, a diff of the top two revisions is
	      sent to the standard output device.  This  is  most  useful  for
	      seeing what the last change to a file was.

	      If you use the -u option, the patch output uses the newer ``uni-
	      diff'' format for context diffs.

	      You can use -c to explicitly specify the `diff -c' form of  con-
	      text diffs (which is the default), if you like.

       release [-dQq] modules...
	      Requires: Working directory.
	      Changes: Working directory, history log.
	      This command is meant to safely cancel the effect of `cvs check-
	      out'.  Since cvs doesn't lock files, it isn't strictly necessary
	      to  use this command.  You can always simply delete your working
	      directory, if you like; but you risk losing changes you may have
	      forgotten,  and  you leave no trace in the cvs history file that
	      you've abandoned your checkout.

	      Use `cvs release' to avoid these problems.  This command	checks
	      that no un-committed changes are present; that you are executing
	      it from immediately above, or inside, a cvs  working  directory;
	      and  that  the repository recorded for your files is the same as
	      the repository defined in the module database.

	      If all these conditions are true, `cvs release' leaves a	record
	      of  its  execution  (attesting  to your intentionally abandoning
	      your checkout) in the cvs history log.

	      You can use the -d flag to request that your working  copies  of
	      the source files be deleted if the release succeeds.

       remove [-lR] [files...]
	      Requires: Working directory.
	      Changes: Working directory.
	      Synonyms: rm, delete
	      Use  this  command to declare that you wish to remove files from
	      the source repository.  Like most  cvs  commands,  `cvs  remove'
	      works  on  files	in your working directory, not directly on the
	      repository.  As a safeguard, it also  requires  that  you  first
	      erase the specified files from your working directory.

	      The  files are not actually removed until you apply your changes
	      to the repository with commit; at that point, the  corresponding
	      RCS  files  in  the source repository are moved into the `Attic'
	      directory (also within the source repository).

	      This command is recursive by default, scheduling all  physically
	      removed files that it finds for removal by the next commit.  Use
	      the -l option to avoid this  recursion,  or  just  specify  that
	      actual files that you wish remove to consider.

       rtag [-falnRQq] [-b] [-d] [-r tag | -D date] symbolic_tag modules...
	      Requires: repository.
	      Changes: repository.
	      Synonym: rfreeze
	      You  can use this command to assign symbolic tags to particular,
	      explicitly specified source versions in  the  repository.   `cvs
	      rtag' works directly on the repository contents (and requires no
	      prior checkout).	Use `cvs tag' instead, to base	the  selection
	      of versions to tag on the contents of your working directory.

	      In general, tags (often the symbolic names of software distribu-
	      tions) should not be removed, but the -d option is available  as
	      a  means	to remove completely obsolete symbolic names if neces-
	      sary (as might be the case for an Alpha release, say).

	      `cvs rtag' will not move a tag that already exists.  With the -F
	      option,  however, `cvs rtag' will re-locate any instance of sym-
	      bolic_tag that already exists on that file to the new repository
	      versions.   Without  the -F option, attempting to use `cvs rtag'
	      to apply a tag that already exists on that file will produce  an
	      error message.

	      The  -b  option makes the tag a ``branch'' tag, allowing concur-
	      rent, isolated development.  This is most useful for creating  a
	      patch to a previously released software distribution.

	      You  can	use  the  standard -r and -D options to tag only those
	      files that already contain a certain tag.  This method would  be
	      used  to	rename a tag: tag only the files identified by the old
	      tag, then delete the old tag, leaving the new tag on exactly the
	      same files as the old tag.

	      rtag executes recursively by default, tagging all subdirectories
	      of modules you specify in the argument.  You  can  restrict  its
	      operation  to top-level directories with the standard -l option;
	      or you can explicitly request recursion with -R.

	      The modules database can specify a program to execute whenever a
	      tag  is specified; a typical use is to send electronic mail to a
	      group of interested parties.  If you want to  bypass  that  pro-
	      gram, use the standard -n option.

	      Use  the	-a option to have rtag look in the `Attic' for removed
	      files that contain the specified tag.  The tag is  removed  from
	      these  files, which makes it convenient to re-use a symbolic tag
	      as development continues (and files get removed from the up-com-
	      ing distribution).

       status [-lRqQ] [-v] [files...]
	      Requires: working directory, repository.
	      Changes: nothing.
	      Display  a  brief  report  on  the  current status of files with
	      respect to the source repository, including any ``sticky'' tags,
	      dates,  or  -k  options.	 (``Sticky'' options will restrict how
	      `cvs update' operates until you reset them; see the  description
	      of `cvs update -A...'.)

	      You can also use this command to anticipate the potential impact
	      of a `cvs update' on your working source directory.  If  you  do
	      not  specify  any  files	explicitly,  reports are shown for all
	      files that cvs has placed in your working  directory.   You  can
	      limit  the  scope of this search to the current directory itself
	      (not its subdirectories) with the standard -l  option  flag;  or
	      you  can explicitly request recursive status reports with the -R
	      option.

	      The -v option causes the symbolic tags for the RCS  file	to  be
	      displayed as well.

       tag  [-lQqR]  [-F]  [-b]  [-d]  [-r  tag  |  -D date] [-f] symbolic_tag
       [files...]
	      Requires: working directory, repository.
	      Changes: repository.
	      Synonym: freeze
	      Use  this command to assign symbolic tags to the nearest reposi-
	      tory versions to your working sources.   The  tags  are  applied
	      immediately to the repository, as with rtag.

	      One potentially surprising aspect of the fact that cvs tag oper-
	      ates on the repository is that you are  tagging  the  checked-in
	      revisions,  which may differ from locally modified files in your
	      working directory.  If you want to avoid doing this by  mistake,
	      specify the -c option to cvs tag.  If there are any locally mod-
	      ified files, CVS will abort with an error  before  it  tags  any
	      files.

	      One  use	for  tags  is  to record a ``snapshot'' of the current
	      sources when the software freeze date of a project arrives.   As
	      bugs are fixed after the freeze date, only those changed sources
	      that are to be part of the release need be re-tagged.

	      The symbolic tags are meant to permanently  record  which  revi-
	      sions  of which files were used in creating a software distribu-
	      tion.  The checkout, export and update  commands	allow  you  to
	      extract  an  exact  copy	of a tagged release at any time in the
	      future, regardless of whether files have been changed, added, or
	      removed since the release was tagged.

	      You  can	use  the  standard -r and -D options to tag only those
	      files that already contain a certain tag.  This method would  be
	      used  to	rename a tag: tag only the files identified by the old
	      tag, then delete the old tag, leaving the new tag on exactly the
	      same files as the old tag.

	      Specifying  the  -f  flag in addition to the -r or -D flags will
	      tag those files named on the command line even if  they  do  not
	      contain the old tag or did not exist on the specified date.

	      By  default  (without a -r or -D flag) the versions to be tagged
	      are supplied implicitly by  the  cvs  records  of  your  working
	      files' history rather than applied explicitly.

	      If  you  use  `cvs tag -d symbolic_tag...', the symbolic tag you
	      specify is deleted instead of being  added.   Warning:  Be  very
	      certain  of  your  ground  before  you  delete a tag; doing this
	      effectively discards  some  historical  information,  which  may
	      later turn out to have been valuable.

	      `cvs  tag' will not move a tag that already exists.  With the -F
	      option, however, `cvs tag' will re-locate any instance  of  sym-
	      bolic_tag that already exists on that file to the new repository
	      versions.  Without the -F option, attempting to use `cvs tag' to
	      apply  a	tag  that  already exists on that file will produce an
	      error message.

	      The -b option makes the tag a ``branch'' tag,  allowing  concur-
	      rent,  isolated development.  This is most useful for creating a
	      patch to a previously released software distribution.

	      Normally, tag executes recursively through  subdirectories;  you
	      can prevent this by using the standard -l option, or specify the
	      recursion explicitly by using -R.

       update [-ACdflPpQqR] [-d] [-r tag|-D date] files...
	      Requires: repository, working directory.
	      Changes: working directory.
	      After you've run checkout to create your private copy of	source
	      from  the  common  repository,  other  developers  will continue
	      changing the central source.  From time to time, when it is con-
	      venient in your development process, you can use the update com-
	      mand from within your working directory to reconcile  your  work
	      with  any revisions applied to  the source repository since your
	      last checkout or update.

	      update keeps you informed of its progress by printing a line for
	      each  file,  prefaced with one of the characters `U P A R M C ?'
	      to indicate the status of the file:

       U file	 The file was brought up to date with respect to  the  reposi-
		 tory.	 This  is done for any file that exists in the reposi-
		 tory but not in your source, and for files that  you  haven't
		 changed but are not the most recent versions available in the
		 repository.

       P file	 Like U, but the CVS server sends a patch instead of an entire
		 file.	This accomplishes the same thing as U using less band-
		 width.

       A file	 The file has been added to your private copy of the  sources,
		 and  will be added to the source repository when you run `cvs
		 commit' on the file.  This is a reminder to you that the file
		 needs to be committed.

       R file	 The  file  has  been  removed	from  your private copy of the
		 sources, and will be removed from the source repository  when
		 you  run `cvs commit' on the file.  This is a reminder to you
		 that the file needs to be committed.

       M file	 The file is modified in  your	working  directory.   `M'  can
		 indicate  one	of  two  states  for a file you're working on:
		 either there were no modifications to the same  file  in  the
		 repository,  so that your file remains as you last saw it; or
		 there were modifications in the repository as well as in your
		 copy, but they were merged successfully, without conflict, in
		 your working directory.

       C file	 A conflict was detected while trying to merge your changes to
		 file with changes from the source repository.	file (the copy
		 in your working directory) is now the result of  merging  the
		 two versions; an unmodified copy of your file is also in your
		 working directory, with the name `.#file.version', where ver-
		 sion  is  the	revision that your modified file started from.
		 (Note that some systems automatically purge files that  begin
		 with  `.#' if they have not been accessed for a few days.  If
		 you intend to keep a copy of your original file, it is a very
		 good idea to rename it.)

       ? file	 file is in your working directory, but does not correspond to
		 anything in the source repository, and is not in the list  of
		 files	for  cvs  to  ignore  (see  the  description of the -I
		 option).


	    Use the -A option to reset any sticky tags, dates, or -k  options.
	    (If  you  get a working copy of a file by using one of the -r, -D,
	    or -k options, cvs remembers the corresponding tag, date, or kflag
	    and  continues  using  it  on future updates; use the -A option to
	    make cvs forget these specifications, and  retrieve  the  ``head''
	    version of the file).

	    The  -jbranch option merges the changes made between the resulting
	    revision and the revision that it is based on (e.g.,  if  the  tag
	    refers to a branch, cvs will merge all changes made in that branch
	    into your working file).

	    With two -j options, cvs will merge in the changes between the two
	    respective	revisions.   This  can be used to ``remove'' a certain
	    delta from your working file.  E.g., If the file foo.c is based on
	    revision 1.6 and I want to remove the changes made between 1.3 and
	    1.5, I might do:

		      example% cvs update -j1.5 -j1.3 foo.c   # note the order...

	    In addition, each -j option can contain on optional date  specifi-
	    cation  which, when used with branches, can limit the chosen revi-
	    sion to one within a specific date.  An optional date is specified
	    by adding a colon (:) to the tag.

		      -jSymbolic_Tag:Date_Specifier

	    Use  the  -d  option  to  create any directories that exist in the
	    repository if they're missing from the working  directory.	 (Nor-
	    mally, update acts only on directories and files that were already
	    enrolled in your working directory.)  This is useful for  updating
	    directories  that were created in the repository since the initial
	    checkout; but it has an unfortunate side effect.  If you  deliber-
	    ately  avoided certain directories in the repository when you cre-
	    ated your working directory (either through use of a  module  name
	    or	by  listing explicitly the files and directories you wanted on
	    the command line), then updating with -d will create those	direc-
	    tories, which may not be what you want.

	    Use  -I name to ignore files whose names match name (in your work-
	    ing directory) during the update.  You can specify	-I  more  than
	    once  on  the command line to specify several files to ignore.  By
	    default, update ignores files whose names match certain  patterns;
	    for  an  up to date list of ignored file names, see the Cederqvist
	    manual (as described in the SEE ALSO section of this manpage).

	    Use `-I !' to avoid ignoring any files at all.

	    Use the `-C' option to overwrite locally modified files with clean
	    copies  from  the  repository  (the  modified  file  is  saved  in
	    `.#file.revision', however).

	    The standard cvs command options -f, -k, -l, -P, -p,  and  -r  are
	    also available with update.

FILES
       For more detailed information on cvs supporting files, see cvs(5).

       Files in home directories:

       .cvsrc The  cvs initialization file.  Lines in this file can be used to
	      specify default options for each cvs command.  For  example  the
	      line  `diff -c' will ensure that `cvs diff' is always passed the
	      -c option in addition to any other options passed on the command
	      line.

       .cvswrappers
	      Specifies  wrappers to be used in addition to those specified in
	      the CVSROOT/cvswrappers file in the repository.

       Files in working directories:

       CVS    A directory of cvs administrative files.	Do not delete.

       CVS/Entries
	      List and status of files in your working directory.

       CVS/Entries.Backup
	      A backup of `CVS/Entries'.

       CVS/Entries.Static
	      Flag: do not add more entries on `cvs update'.

       CVS/Root
	      Pathname to the repository ( CVSROOT ) location at the  time  of
	      checkout.   This file is used instead of the CVSROOT environment
	      variable if the environment variable is not set.	A warning mes-
	      sage  will be issued when the contents of this file and the CVS-
	      ROOT environment variable differ.  The file may  be  over-ridden
	      by  the presence of the CVS_IGNORE_REMOTE_ROOT environment vari-
	      able.

       CVS/Repository
	      Pathname to the corresponding directory in  the  source  reposi-
	      tory.

       CVS/Tag
	      Contains	the  per-directory ``sticky'' tag or date information.
	      This file is created/updated when you specify -r or  -D  to  the
	      checkout or update commands, and no files are specified.

       CVS/Checkin.prog
	      Name of program to run on `cvs commit'.

       CVS/Update.prog
	      Name of program to run on `cvs update'.

       Files in source repositories:

       $CVSROOT/CVSROOT
	      Directory of global administrative files for repository.

       CVSROOT/commitinfo,v
	      Records programs for filtering `cvs commit' requests.

       CVSROOT/cvswrappers,v
	      Records cvs wrapper commands to be used when checking files into
	      and out of the repository.  Wrappers allow the file or directory
	      to be processed on the way in and out of CVS.  The intended uses
	      are many, one possible use would be to reformat a C file	before
	      the  file  is  checked  in, so all of the code in the repository
	      looks the same.

       CVSROOT/editinfo,v
	      Records  programs  for  editing/validating  `cvs	 commit'   log
	      entries.

       CVSROOT/history
	      Log file of cvs transactions.

       CVSROOT/loginfo,v
	      Records programs for piping `cvs commit' log entries.

       CVSROOT/modules,v
	      Definitions for modules in this repository.

       CVSROOT/rcsinfo,v
	      Records pathnames to templates used during a `cvs commit' opera-
	      tion.

       CVSROOT/taginfo,v
	      Records programs for validating/logging `cvs tag' and `cvs rtag'
	      operations.

       MODULE/Attic
	      Directory for removed source files.

       #cvs.lock
	      A  lock directory created by cvs when doing sensitive changes to
	      the source repository.

       #cvs.tfl.pid
	      Temporary lock file for repository.

       #cvs.rfl.pid
	      A read lock.

       #cvs.wfl.pid
	      A write lock.

ENVIRONMENT
       CVSROOT
	      Should contain the full pathname to the root of the  cvs	source
	      repository  (where  the  RCS  files are kept).  This information
	      must be available to cvs for most commands to execute;  if  CVS-
	      ROOT  is	not set, or if you wish to override it for one invoca-
	      tion, you can supply it on the command  line:  `cvs  -d  cvsroot
	      cvs_command...'  You  may  not  need  to set CVSROOT if your cvs
	      binary has the right path compiled in.

       CVSREAD
	      If this is set, checkout and update will try hard  to  make  the
	      files  in  your  working	directory read-only.  When this is not
	      set, the default behavior is  to	permit	modification  of  your
	      working files.

       CVSREADONLYFS
	      If  this	is  set, the -R option is assumed, and cvs operates in
	      read-only repository mode.

       RCSBIN Specifies the full pathname where to find RCS programs, such  as
	      co(1) and ci(1) (CVS 1.9 and older).

       CVSEDITOR
	      Specifies  the  program to use for recording log messages during
	      commit.  If not set, the VISUAL and EDITOR environment variables
	      are  tried  (in that order).  If neither is set, a system-depen-
	      dent default editor (e.g., vi) is used.

       CVS_CLIENT_PORT
	      If this variable is set then cvs will use this port  in  pserver
	      mode rather than the default port (cvspserver 2401).

       CVS_IGNORE_REMOTE_ROOT
	      If  this	variable is set then cvs will ignore all references to
	      remote repositories in the CVS/Root file.

       CVS_OPTIONS
	      Specifies a set of default options for cvs.  These  options  are
	      interpreted  before  the startup file (~/.cvsrc) is read and can
	      be overridden by explicit command line parameters.

       CVS_RSH
	      cvs uses the contents of this variable to determine the name  of
	      the  remote shell command to use when starting a cvs server.  If
	      this variable is not set then `ssh' is used.

       CVS_SERVER
	      cvs uses the contents of this variable to determine the name  of
	      the  cvs server command.	If this variable is not set then `cvs'
	      is used.

       CVSWRAPPERS
	      This variable is used by the `cvswrappers' script  to  determine
	      the  name  of  the  wrapper  file,  in  addition to the wrappers
	      defaults contained in the repository  (CVSROOT/cvswrappers)  and
	      the user's home directory (~/.cvswrappers).

AUTHORS
       Dick Grune
	      Original	author	of  the  cvs  shell  script  version posted to
	      comp.sources.unix in the	volume6  release  of  December,  1986.
	      Credited with much of the cvs conflict resolution algorithms.

       Brian Berliner
	      Coder  and  designer  of	the cvs program itself in April, 1989,
	      based on the original work done by Dick.

       Jeff Polk
	      Helped Brian with the design of the cvs module and vendor branch
	      support  and author of the checkin(1) shell script (the ancestor
	      of `cvs import').

       And many others too numerous to mention here.

SEE ALSO
       The most comprehensive manual for CVS is Version Management with CVS by
       Per Cederqvist et al.  Depending on your system, you may be able to get
       it with the info cvs command or it may be available  as	cvs.ps	(post-
       script), cvs.texinfo (texinfo source), or cvs.html.

       For CVS updates, more information on documentation, software related to
       CVS, development of CVS, and more, see:
		 http://cvshome.org http://www.loria.fr/~molli/cvs-index.html

       ci(1), co(1), cvs(5), cvsbug(8), diff(1),  grep(1),  patch(1),  rcs(1),
       rcsdiff(1), rcsmerge(1), rlog(1).



									CVS(1)
=30097
+53
(5)