[12pt,twoside] article 

  ifpdf     [pdftex] graphicx   =9
  thumbpdf    epstopdf      graphicx      array    lscape    makeidx    natbib    times    url  
   [backref,breaklinks,colorlinks,citecolor=blue,linkcolor=blue,urlcolor=blue,hyperindex,plainpages=false,pdftex] hyperref   =9
   [backref=false,breaklinks,colorlinks=false,hyperindex,plainpages=false] hyperref    
  csz    jrn agu  
  
     : 

  -24pt   12pt   12pt
  9in   6.5in
  0in   0in
  0pt   0pt
  24pt
 =0pt

  secnumdepth  6 

document  

center  
Online version:   http://dust.ess.uci.edu/doc/cvs     





     CVS Cheat Sheet  



by Charlie Zender

University of California, Irvine

center  
Department of Earth System Science   zender@uci.edu

University of California   Voice: (949)  824-2987

Irvine, CA  92697-3100   Fax: (949)  824-3256

  roman 
  page  1 
  headings 
  empty 


  arabic 
  page  1 
  empty 

  Software Configuration Management 
The process of orderly tracking, versioning, and serving, and
administration of project source code is called
  Software Configuration Management  (  SCM ).
This document describes two different software tools which aid in SCM:
  http://www.cvshome.org    Concurrent Versioning System  
(  CVS ) and 
  http://subversion.tigris.org    Subversion   (  SVN ).
These tools are intimately related since SVN is designed by some of
the original authors of CVS to replace CVS.
Currently, all of Section   sxn:cvs  (99% of this document)
is devoted to CVS, while the newer portions, Section   sxn:svn ,
is devoted to SVN.

  CVS   sxn:cvs 

Section   sxn:cvs gnr  presents the generic CVS commands.
The commands proceed in order of increasing complexity. 
After that, there are working examples from a number of specific
modules.  

  CVS Preliminaries   sxn:cvs prl 

  Abbreviations 
The following abbreviations are used:
  CWD  means the working copy of the CVS module in and beneath
the   Current Working Directory ;   mdl  = module name;
  fl  = file name;   brnch  = branch tag; 
  vrs  = version name (which can be a branch tag).

  CVS Keywords 
Only ``  cvs commit '', ``  cvs tag '', and ``  cvs
rtag '' change the repository. All other CVS commands change, if
anything, the contents of the CWD only, and so are recoverable. 
CVS commands should be executed from the top level of the CWD.
In this case, the module name   mdl  may be optional at the
end of the command (because CVS finds the module name by looking in
the ``CVS'' subdirectory  'mdl/CVS'). 
Executing CVS commands from one level above the module requires
specification of the module name so that CVS knows where to find
 'mdl/CVS'. 

In addition to the usual RCS keywords (  Header ,   Date ,
 ), CVS defines the keyword   Name .  
The string ``  $Name$ '' expands to include the tag specified 
when the module was checked out, e.g., ``  cvs co -r ccm3_5_22
ccm '' produces ``  $Name  ccm3_5_22 $ '' but
``  cvs co ccm '' produces ``  $Name  $ '' for
two reasons. 
First, no tag was specified with the checkout so the default
 'ccm' module, i.e., the main trunk, is retrieved.
The main trunk has no default tag name, so the keyword value is an
empty string. 
Second, checking out the main trunk never expands
``  $Name$ '', but checking out a branch, any branch, does.
Branch tags are sticky, so a branch always has an associated tag
name. 
The rest of the RCS keywords expand to their usual meanings regardless
of whether the module is a tagged version or branch.
To explicitly turn off CVS keyword expansion when checking out a
module (recommended to avoid unnecessary conflicts due to CVS metadata
changes), use  the ``  -kk '' option instead of the default,
``  -kkv ''.   
The  '-k' options are   sticky , meaning they apply to any
derived files as well.

  CVS Errors 
Occasionally CVS does not perform as expected.
Two errors are particularly frequent, and easy to fix.
The first is that, when asked to commit files to the repository, CVS
complains that some subset of the files is out-of-date, and asks you
to fix this before it proceeds. 
This is, in fact, not an error, but very helpful behavior by CVS
telling you that somehow your working directory is out of date with
respect to the repository. 
Some versions of CVS will commit those files that are modified but not
commit those that are out of date.
Other versions of CVS will not commit any file until all files in the
CWD are current.
In this case, simply perform a ``  cvs update '' before
attempting to ``  cvs commit '' again.
This should solve the problem.

The second error occurs when CVS attempts to modify the repository,
e.g., during a ``  cvs commit '' operation, and it complains
that it has never heard of any of the files, e.g., ``  cvsbin
commit: nothing known about `to' ''. 
If this occurs on the CGD Sun network, it might be because you have
used simply  'cvs' rather than  'cvsbin' as the CVS command.
Check this and try your command again.

  CVS Debugging 
When attempting to solve problems with CVS, try using the
``  -t '' switch so CVS will trace its execution.

  CVS Environment Variables 
CVS makes use of several   environment variables .
verbatim  
export CVS RSH='ssh'    # Needed for ssh access to NCAR CGD CVS
export CVSROOT=':ext:dust.ess.uci.edu:/home/zender/cvs'
export CVSUMASK='002'   # Default file permissions for CVS
verbatim  

  CVS Administration 
In order to execute the   cvs admin  command, the user must be a
member of the   cvsadmin  group, if it exists.
verbatim  
cvs admin -oREV::
cvs admin -mREV:MSG Replace the log message of revision REV with MSG.
verbatim  

It took five years since I began using CVS in 1998 before I needed to
learn how to use CVS administrative commands to repair repositories.
On July 30, 2003 the laptop I was using ran out of power and somehow
wrote binary garbage into every file that   emacs  was
visiting. 
I only lost a few hours of work, and it seemed like time to backup 
everything I was working on.
That made things a little worse because I incidentally committed the
binary garbage to CVS. 
How did I remove the binary garbage from the repository?
verbatim  
# Replace corrupt file with latest working backup
cvs update -r 1.65 -p pnp.tex > pnp.tex
# Delete garbage file from repository
cvs admin -o 1.65:1.67 pnp.tex # Method 1: Collapse everything between 
cvs admin -o 1.66 pnp.tex # Method 2: Delete a specific version
# Delete garbage file from repository
cvs update -r 1.53 -p prp mri.tex > prp mri.tex
cvs admin -o 1.54 prp mri.tex
verbatim  

  Repository Relocation   sxn:rlc 
Occassionally a CVS repository moves and one must adjust the
 repository location in all modules that were checked out from that
 repository. 
One method of doing this is simply deleting the old modules and then
 checking them out from the new location.
This works fine unless the module is not synchronized with the
 repository, i.e., if there is new work that has not been checked in. 
In this case it may be wiser to edit the repository location in the 
checked out modules, rather than re-checking out the modules.
verbatim  
# Modules in repository on esmf.ess.uci.edu 
mdl lst='aca aeroce aeronet afgl anl anv arese avhrr c caco3 ccm ck cld clm crr
dmr dot dst elisp erbe ess ess acc ess atm ess bnd ess ccc ess lsp
ess phz ess prc ess rdn facts frc fsf grd hdf hire idea idl idx rfr
igbp igpp improve ipcc job jrn linux lsm ltr map match mk
mny ncep ncl perl phd poetry pr prp rt rvw sdn slr spc specfun tex
time toms uci www' 
mdl lst='bxm c++ esmf f mie mie ww ppr BiZ03 ppr BiZ04 ppr FlZ05
ppr GrZ04 ppr ZMT04 ppr ZeK05 ppr ZeT06b ppr ZeT06 prp gtcp
prp itr sltsbl'
mdl lst='nco'
for mdl in  mdl lst  ; do
  cd  HOME / mdl 
  printf "Updating module  mdl ... "
  for fl in `find . -name Root -print` ; do
    printf "Updating Root name in  fl ... "
#   echo 'zender@goldhill.cgd.ucar.edu:/home/zender/cvs' >  fl 
#   echo 'zender@nco.cvs.sf.net:/cvsroot/nco' >  fl 
#   echo 'zender@esmf.ess.uci.edu:/u/zender/cvs' >  fl 
    echo ':ext:zender@nco.cvs.sf.net:/cvsroot/nco' >  fl 
  done # end loop over fl
done # end loop over mdl
for mdl in  mdl lst  ; do
  cd  HOME / mdl 
  printf "Updating module  mdl ... "
  for fl in `find . -name Repository -print` ; do
    printf "Updating Repository name in  fl ... "
    echo  mdl  >  fl 
  done # end loop over fl
done # end loop over mdl

# Modules in repository on goldhill.cgd.ucar.edu
aer -> /home/zender/match dst/dst
cam2 0 2 dev41 brnchT dust2
cam dev
ccm dst
ccsm2
ccsm2 2 beta08
clm2 deva 52
clm dev
crm
match dst

# Modules in repository on dust.ess.uci.edu
bxm
c++
esmf
f
mie
mie ww
ppr BiZ03
ppr BiZ04
ppr FlZ05
ppr GrZ04
ppr ZMT04
ppr ZeK05
ppr ZeT06b
ppr ZeT06
prp gtcp
prp itr
sltsbl

# Modules in repository on sf.net
nco
verbatim  

  Modules   sxn:cvs mdl 
To create a CVS repository, use
verbatim  
cvs -d  HOME /cvs init
verbatim  
The following subsections present specific examples for both generic
and CGD-related modules. 
Many of the same examples are used for different modules, so that the
examples might differ only in the name of the target module, and
sometimes not at all (e.g., ``  cvs co '').
The goal has been to keep the examples self-contained for each
module, at the expense of document length and redundancy. 
The examples are drawn from modules in active use in CGD.
Table   tbl:rps  summarizes the three repositories used in the
examples. 
landscape  
table  
center  
tabular   l l >   l<   >   l<   
    0.0ex    Software & Machine & Repository Location & Module(s) 



    0.0ex     , mie    cvs -d :ext:dust.ess.uci.edu:/home/zender/cvs co -kk mie   &   dust.ess.uci.edu  & /home/zender/cvs & c++ mie 

NCO &   cvs.nco.sourceforge.net  & /cvsroot/nco & nco 

CCM, CCM-Dust, CRM &   goldhill.cgd.ucar.edu  & /fs/cgd/csm/models/CVS.REPOS & ccm ccm_dst crm 

MATCH, MATCH-Dust &   goldhill.cgd.ucar.edu  & /fs/cgd/csm/people/eaton/CVS & match match_dst dst 

CAM &   goldhill.cgd.ucar.edu  & /fs/cgd/csm/models/CVS.REPOS & cam2_0_2_dev41_brnchT_dust2 



tabular  
  CVS Repositories Used in Examples  tbl:rps     
center  
table  
landscape  
Most of the examples do not explicitly specify the repository (with
the  '-d' argument).
This is because most commands are executed within, rather than above,
the CWD.
Table   tbl:rps   should be consulted when the repository to use
is in doubt. 

  CVS Server Issues   sxn:cvs srv 
A precise discussion of setting up a CVS server is given at
  http://www.korayguclu.de/index.php?&file=linux.cvs.pserver.xml .
The CVS documentation describes the necessary modifications to the
internet   daemon  configuration file   /etc/inetd.conf .
  RedHat Linux  uses a more powerful and complex
(some call this sophisticated) daemon,   xinetd  (pronounced 
``zy-net-d''), configured in   /etc/xinetd.conf .
On RedHat systems, CVS password server services are controlled by a
file called   cvspserver  located in   /etc/xinetd.Dachau's .
verbatim  
# Others
sudo scp  /linux/etc/inetd.conf.dust /etc/inetd.conf
# RedHat
sudo scp  /linux/etc/xinetd.d/cvspserver /etc/xinetd.d
sudo /etc/rc.d/init.d/xinetd restart
verbatim  
The CVS documentation specifies how to configure the   port
  number  (2401),   socket_type , and   server_args 
  flags.
Internet daemon services (i.e.,   inetd  or   xinetd )
should be started automatically, in, say, system   runlevel  3. 

 [Read-only Access] Read-only Access   sxn:cvs read 
Place the   readers ,   writers , and   passwd  file
in the directory    CVSROOT /CVSROOT .
verbatim  
cd  HOME /cvs/CVSROOT
chmod 644 readers writers
chmod 444 readers writers
sci prg
jtalaman
mflanner
zender
mflanner
sci prg::cvspub
esmf::cvspub
verbatim  
Add user   cvspub  to the system.
Do not give the user a home directory or interactive access.

Once read-only services work, outside users may check out 
modules by logging in as the   anonymous user .
verbatim  
cvs -d :pserver:sci prg@dust.ess.uci.edu:/home/zender/cvs login
cvs -d :pserver:sci prg@dust.ess.uci.edu:/home/zender/cvs co -kk c++
verbatim  

  Generic Modules   sxn:cvs gnr 

 [Import] Import an existing directory   sxn:cvs mpr 
Import files in directory  'mdl' to create new CVS module
 'mdl'.    
The keywords ``zender'' (vendor tag) and ``mdl-0_1'' (release tag)
are used for initial module tags. 
verbatim  
cd mdl
cvs import -m "Imported sources" mdl zender mdl-0 1
cvs -d :ext:dust.ess.uci.edu:/home/zender/cvs import -m "Imported sources" mdl zender mdl-0 1
cd ..
mv mdl mdl.bck
cvs co -kk mdl
ls -R mdl
/bin/rm -r mdl.bck
verbatim  

 [Import RCS] Import RCS files 
Edit the CVS repository to create the appropriate source directories. 
Make sure all RCS files are unlocked, then copy them into the CVS
repository. 
verbatim  
cd mdl/RCS
rcs -u *
mkdir  CVSROOT /mdl
cp .*,v *,v  CVSROOT /mdl
cd ../..
mv mdl mdl.bck
cvs co mdl
ls -R mdl
/bin/rm -r mdl.bck
verbatim  

 [Checkout] Checkout 
Checkout module  'mdl'. A  '-d' argument before the
verb specifies the CVS repository to use (instead of
  $CVSROOT ). By default, a module  'mdl' is placed in the  'mdl' directory
of the CWD. 
A  '-d' argument after the verb specifies an arbitrary directory
for the module.
The  '-kk' option suppresses RCS keyword expansion (e.g., of
``  $Header : $ ''), thereby minimizing the number of
conflicts during a future   cvs update . 
Note that  'co' is a synonym for  'checkout'---the two are
interchangeable. 
verbatim  
cvs co mdl     # Expands keywords
cvs co -kk mdl # Does not expand keywords. Use prior to cvs update.
cvs checkout -d drc mdl
cvs -d /fs/cgd/csm/models/CVS.REPOS co mdl
cvs -d /fs/cgd/csm/models/CVS.REPOS co -d drc mdl
verbatim  

 [Add] Add 
Schedule file  'fl' for addition to the repository.  
Actual addition takes effect with the next ``  cvs commit ''
command.
  
 'cvs add fl'

 [Remove] Remove 
Schedule file  'fl' for removal from the repository.  
Actual removal takes effect with the next ``  cvs commit ''
command.
 
 'cvs remove fl'

 [Query] Query 
Show changes of CWD relative to repository. 
Option  '-n' specifies that no changes to the repository will
occur.
  
 'cvs -n update'

 [Diff] Diff 
Show changes relative to particular versions, tags, or times.
verbatim  
cvs diff -kk main.c
cvs diff -r ccm3 6 -kk main.c
cvs diff -r 1.1 -kk main.c
cvs diff -D "last week" -kk main.c
cvs diff -D "4 days ago" -kk main.c
cvs diff -D "3/12/98" -kk main.c
verbatim  
Revert repository to state it was in 24 hours before.
Use  '-p' switch to overwrite version in current directory.
This prevents CVS from applying sticky flag to new versions.
verbatim  
cvs update -D "24 hours ago" -p ncap.h > ncap.h
cvs update -D "24 hours ago" -p ncap lex.l > ncap lex.l
cvs update -D "24 hours ago" -p ncap yacc.y > ncap yacc.y
cvs update -D "24 hours ago" -p ncap utl.c > ncap utl.c
verbatim  
Checkout a date-stamped version of a module:
verbatim  
cvs -z3 -d zender@nco.cvs.sf.net:/cvsroot/nco co -D 20050524 -d nco-20050524 nco
verbatim  
Compare module files from two different dates:
verbatim  
cvs diff -c --ignore-all-space -kk -D 20050519 -D 20050520 
verbatim  

 [Commit] Commit 
Commit changes beneath CWD. 
The  'commit' verb accepts optional filename arguments for
file-by-file (rather than entire module) commits.
verbatim  
cvs commit                # Invokes editor for log message
cvs commit -m "fixed bug" # Uses "fixed bug" for log message
cvs commit README         # Only commits README file
verbatim  

 [Tag] Tag 
Tag CWD with  'mdl-1 0'. 
Option  '-c' causes  'tag' to verify that files beneath CWD
are not modified relative to the repository. 
This ensures the repository has all the information needed to exactly
reproduce the CWD from the tag name in the future (with, e.g.,
``  cvs co -r mdl1_0 mdl ''.
verbatim  
cvs tag -c mdl-1 0     # From top-level of CWD
cvs tag -c mdl-1 0 mdl # Above top-level of CWD
verbatim  

 [Rtag] Rtag 
``Repository'' tag ( 'rtag') the module with  'tag nm'.
Verb  'rtag', as opposed to  'tag', operates on the
repository, not the CWD.  
Does this only tag those portions of the repository in and beneath the
CWD? (fxm).
By default,  'rtag' tags the most recent version of the
module. 
This can be overridden with  '-D date' option.
Use ( 'rtag') with caution on branches, because it will update the
main repository as well (fxm).

 'cvs rtag tag nm'

 [Release] Release 
Release module  'mdl' and delete its working
directories. 
CVS prompts the user whether to actually delete the directory:
   
 'cvs release -d mdl # From level above CWD' 

 [Update] Update 
Update the CWD for  'mdl' so that it reflects the latest 
version of the repository. 
One, and only one,  '-j' option, ``  -j vrs '', updates
the CWD of  'mdl' to the latest revision of the   ancestor 
of  'vrs'.  
The ancestor is the model from which the  'vrs' branch split.
Given two  '-j' options, ``  -j vrs1 -j vrs2 '', 
the  'update' command takes the differences (uses  'diff')
between version  'vrs1' and version  'vrs2' and
applies them (uses  'patch') to the CWD.
The  '-kk' option suppresses RCS keyword expansion, thereby
minimizing the number of conflicts during an update.
For this reason, it is wise to use   cvs co -kk mdl 
before using   cvs update .
verbatim  
cvs update      # Update all files in module
cvs update *    # Update currently checked-out files only
cvs update mdl  # Above top-level of CWD
cvs update -kk
cvs update -kk -d # Add directories not in working copy
cvs update -j vrs -kk
cvs update -j vrs1 -j vrs2 -kk
cvs update -kk -p params.h > foo        # Redirect file to stdout
# Replace modified file with repository file
cvs update -kk -p params.h > params.h   
verbatim  

  C++ Module   sxn:cvs c++ 
The C++ module  'c++' was imported using ``  cvs import -m
"Imported sources" c++ zender c++-1_0 ''. 

 [Checkout] Checkout 
Checkout the latest version of the C++ module. 
verbatim  
# From NCAR, from  
cvsbin co c++
# From home, from  
cvs -d :pserver:zender@bearmtn.cgd.ucar.edu:/home/zender/cvs login
cvs -d :pserver:zender@bearmtn.cgd.ucar.edu:/home/zender/cvs co -kk c++
# From UCI, from  
cvs -d :ext:zender@goldhill.cgd.ucar.edu:/home/zender/cvs co -kk c++
verbatim  

 [Commit] Commit 
Commit C++ CWD to remote repository.
One of the nicest feature about CVS is that it knows about remote
repositories, so commands like  'commit' and  'update' need no
extra arguments.
verbatim  
# Update CWD at home and continue working
cvs update c++ # From home  /
# Commit CWD at home to repository at NCAR
cvs commit c++ # From home  /
verbatim  

  NCO Module   sxn:cvs nco 

The NCO module  'nco' was imported using ``  cvs import -m
"Imported sources" nco zender nco-1_0 ''. 

 [Checkout] Checkout 
Checkout the latest version of the NCO module. 
verbatim  
# From home, from  /nc
cvs -d :pserver:zender@bearmtn.cgd.ucar.edu:/home/zender/cvs login
cvs -d :pserver:zender@bearmtn.cgd.ucar.edu:/home/zender/cvs co nco
verbatim  

 [Update] Update 
Update a remote module (i.e., at home) to the current NCAR NCO
repository. 
verbatim  
cvs status
cvs -n update
cvs update      # Update all files in module
cvs update *    # Update currently checked-out files only
verbatim  

  CRM Module   sxn:cvs ccm crm 

The CRM module  'crm' was created as a branch of CCM version
3.5.22.
First, we defined module  'crm' by editing the
 '/fs/cgd/csm/models/CVS.REPOS/CVSROOT/modules' file to contain
the following lines: 
verbatim  
...
# CCM Column models
crm atm/ccm crm &ccm crm src
ccm crm src -d src atm/ccm crm src &eul &physics &ccmlsm share &dom &csm share &
srchutil &control
...
verbatim  
Finally, we executed the following commands to create the CRM branch
of the CCM:
verbatim  
cvs co -r ccm3 5 22 crm
cd src/crm
cvs tag -b ccm brnch crm 
cd src/control
cvs tag -b ccm brnch crm [list of files in control needed by CRM]
cd src/physics
cvs tag -b ccm brnch crm [list of files in physics needed by CRM]
...
verbatim  
Note that we used  'tag' rather than  'rtag' in the above
because only  'tag' allows one to tag a specified subset of the
files in a given module.
In this case, the desired subset was the CCM files which are also
required by the CRM, but no others (this excluded superfluous files,
e.g.,  'vdiff.F').
All work on the CRM module is actually performed on this
 'ccm brnch crm' branch of the CRM, rather than the CRM main trunk
This methodology, i.e., working on the branch rather than the main
trunk, is also used for the Dust module component of CCM, MATCH, and
MOZART described in Sections   sxn:cvs ccm dst ,   sxn:cvs match dst ,
and   sxn:cvs mozart dst  respectively.  

 [Create Distribution] Create Distribution 
Release a new CRM.
This process uses many CVS commands.
First, make sure the  'crm' module in the repository is
up-to-date, so that the CWD can be exactly reproduced.
Second, release the module. 
Third, check out the CRM with the  '-kk' option. 
Fourth, difference the CWD with the most recent branch tag.
This difference file shows the differences between the releases.
Do these differences make sense?
Fifth, tag the module.
Sixth, execute the distribution script.
verbatim  
cd ..                   # Move above top-level of CWD
cvs commit crm          # Above top-level of CWD
cvs release -d crm      # Above top-level of CWD
cvs -d /fs/cgd/csm/models/CVS.REPOS co -r ccm brnch crm -kk crm
cvs diff -kk -r ccm3 6 crm > pre.diff
cvs tag -c ccm3 6 brnchT crm2 0 crm
crm dst.pl --dbg=1 ccm3 6 brnchT crm2 0
verbatim  

 [Update] Update to newer CCM version 
Update the CWD to a newer CCM version.
This process uses many CVS commands.
First, checkout a clean copy of the CRM branch into the CWD.
Second, difference the pre-merged CRM from its current CCM base.
This difference file shows all the CRM-specific modifications to the
current CCM base code.
Third, update the CWD to the desired CCM version.
Given two  '-j' options, (``  -j ccm3_5_22 -j
ccm3_6_0 ''), the  'update' command takes the differences (uses
 'diff') from CCM version  'ccm3 5 22' to CCM version
 'ccm3 6 0' and applies them (uses  'patch') to the CWD.
Fourth, examine and fix the conflicts caused by this merge.
Use, e.g., ``  cvs status '' to locate conflicts.
Make sure to compile, test, and generate new *.out files for the
updated model.
This ensures that any new source files will be included in
 'Srcfiles' and  'Depends'.
Also, it is important to compile with
``  -DSINGLE_SOURCE_FILE '' option.
This verifies that any new files merged into, and needed by, the CRM
are accounted for.
Unfortunately, there is no simple way to ensure that superfluous
source files have not crept into the CRM.
Fifth, difference the post-merged CRM from the new CCM base.
This difference file shows all the CRM-specific modifications to the
new CCM base code.
Sixth, difference the two difference files.
This file highlights conflicts caused by the merge process and,
hopefully, any mistakes CVS made in performing the update.
Seventh, commit the updated code to the head of the branch.
Eighth, if desired, tag the branch as a new release of CRM.
verbatim  
# Above top-level of CWD
cvs -d /fs/cgd/csm/models/CVS.REPOS co -r ccm brnch crm -kk crm
cvs diff -kk -r ccm3 5 22 crm > pre.diff
cvs update -j ccm3 5 22 -j ccm3 6 crm
cvs status crm | grep -i conflict
cvs diff -kk -r ccm3 6 crm > post.diff
diff pre.diff post.diff > diff.diff
cvs commit crm
cvs tag -c ccm3 6 brnchT crm2 0 crm
verbatim  

 [Checkout] Checkout 
Checkout the latest version of the CRM. 
By default, the  'crm' module is placed in the  'crm'
directory of the CWD. 
A  '-d' argument after the verb specifies an arbitrary
directory.
verbatim  
cvs co -r ccm brnch crm -kk crm
cvs -d /fs/cgd/csm/models/CVS.REPOS co -r ccm brnch crm -kk crm
cvs -d /fs/cgd/csm/models/CVS.REPOS co -r ccm brnch crm -d drc crm
cvs -d :pserver:zender@goldhill.cgd.ucar.edu:/fs/cgd/csm/models/CVS.REPOS 

co -r ccm brnch crm -kk crm
verbatim  

 [Export] Export 
Export the latest version of the module  'crm' from CCM
branch  'ccm brnch crm' into directory
 '/data/zender/crm-1.1' and prepare a compressed tarfile
distribution.  
The  'export' command strips all the CVS directories from the
output.  
This is most useful for creating distributions for public release. 
Using  '-kkv' instead of  '-kv' would expand CVS keywords into
keywords plus values. 
verbatim  
/bin/rm -r -f /data/zender/crm-1.1
cvs export -kv -r ccm brnch crm -d /data/zender/crm-1.1 crm
cd /data/zender; gtar -cvzf crm-1.1.tar.gz ./crm-1.1
verbatim  

 [Tag] Tag 
Tag CWD with  'ccm3 6 brnchT crm2 0'. 
Option  '-c' causes  'tag' to verify that files beneath CWD
are not modified relative to the repository. 
This ensures the repository has all the information needed to exactly 
reproduce the CWD from the tag name in the future. 
Note it is wise to tag only modules which have been checked out  
with the  '-kk' option.
This prevents large numbers of trivial differences between tagged
versions.
  
 'cvs tag -c ccm3 6 brnchT crm2 0'

 [Remote Checkout] Remote Checkout 
Checkout the latest version of the CRM from home. 
The first  '-d' option specifies the remote repository.
The second  '-d' option specifies the name of the directory to place the
module in.
The final argument,  'crm', is the name of the module to checkout.
For unknown reasons this command erroneously places the src directories one
level too high in most cases.
This is apparently a CVS bug fixed in later versions of CVS.
verbatim  
cvs -d :ext:zender@goldhill.cgd.ucar.edu:/fs/cgd/csm/models/CVS.REPOS 

co -r ccm brnch crm -N -d crm crm
verbatim  
Here is a workaround for the above problem:
verbatim  
mv ccmlsm share dom physics srchutil control csm share eul src
mv src crm
verbatim  

  CCM-Dust Module   sxn:cvs ccm dst 
The module  'ccm dst' comprises the sub-modules  'ccm' and
 'dst'. 
Thus  'ccm dst' is the complete CCM with the dust modifications. 
Code modifications related to dust appear in the usual files in
 'src' (e.g., file  'physics/aphys.F'). 
Most of the dust physics are isolated in the new directory
 'src/dust'.  
The branch  'ccm brnch dst' was created as a branch of CCM version
3.5.22.
First, we defined module  'ccm dst' by editing the
 '/fs/cgd/csm/models/CVS.REPOS/CVSROOT/modules' file to contain
the following lines: 
verbatim  
...
# Atmospheric models
ccm             atm/ccm &ccm src &ccm tools
ccm dst         atm/ccm &ccm dust src &ccm tools
...
#  Sub-modules to ccm
ccm src -d src atm/ccm src &dynamics &physics &control &spmd &dom &som 

                &lsm &ccmlsm share &csm share &mathutil &srchutil
ccm dust src -d src atm/ccm src &dst &dynamics &physics &control &spmd &dom &som 

                &lsm &ccmlsm share &csm share &mathutil &srchutil
...
physics         atm/ccm src dirs/physics
dst             atm/ccm src dirs/dust
...
verbatim  
Finally, we executed the following commands to create the Dust branch
of the CCM:
verbatim  
cvs co ccm dst
cd ccm dst
cvs tag -b ccm brnch dst
verbatim  

 [Checkout] Checkout 
Checkout the latest version of the CCM-Dust module. 
A  '-d' argument after the verb specifies an arbitrary directory
for the module.
verbatim  
cd /fs/cgd/data0/zender
cvsbin -d /fs/cgd/csm/models/CVS.REPOS co -r ccm brnch dst -kk ccm dst
# From home, from  /fsh/dst 
cvs -d :ext:zender@goldhill.cgd.ucar.edu:/fs/cgd/csm/models/CVS.REPOS 

co -r ccm brnch dst -kk ccm dst
cvs -d :pserver:zender@goldhill.cgd.ucar.edu:/fs/cgd/csm/models/CVS.REPOS  
co -r ccm brnch dst -kk ccm dst 
# From UCI
cvs -d :ext:zender@goldhill.cgd.ucar.edu:/fs/cgd/csm/models/CVS.REPOS co -r ccm brnch dst -kk ccm dst 
# CCM Box model only
cvs -d :ext:zender@goldhill.cgd.ucar.edu:/fs/cgd/csm/models/CVS.REPOS co -r ccm brnch dst -kk -d aer dst
# Standard CCM, from UCI
cvs -d :ext:zender@goldhill.cgd.ucar.edu:/fs/cgd/csm/models/CVS.REPOS co -kk -d ccm o2x ccm
cvs -d :ext:zender@goldhill.cgd.ucar.edu:/fs/cgd/csm/models/CVS.REPOS co -r ccm3 10 -d ccm o2x ccm
# Source directory only 
cvs -d :ext:zender@goldhill.cgd.ucar.edu:/fs/cgd/csm/models/CVS.REPOS co -r ccm3 10 -d src ccm src
cvs -d :ext:zender@goldhill.cgd.ucar.edu:/fs/cgd/csm/models/CVS.REPOS co -kk -d src ccm src
# Then when updating parent, use cvs update -l -kk for local update only
# Marianna's dust CLM
cvs -d :ext:zender@goldhill.cgd.ucar.edu:/fs/cgd/csm/models/CVS.REPOS co -r clm2 deva 52 -d clm2 deva 52 clm2
# Natalie's dust CAM/CLM
cvs -d :ext:zender@goldhill.cgd.ucar.edu:/fs/cgd/csm/models/CVS.REPOS co -r cam2 0 2 dev41 brnchT dust2 -d cam2 0 2 dev41 brnchT dust2 cam1
# Head of CAM 
cvs -d :ext:zender@goldhill.cgd.ucar.edu:/fs/cgd/csm/models/CVS.REPOS co -r cam dev -d cam dev cam1
# SNICAR
cvs -d :ext:zender@goldhill.cgd.ucar.edu:/fs/cgd/csm/models/CVS.REPOS rtag -b -r cam3 0 25 cam3 0 25 brnch snicar cam1
cvs -d :ext:zender@goldhill.cgd.ucar.edu:/fs/cgd/csm/models/CVS.REPOS co -kk -r cam3 0 25 brnch snicar -d cam snicar cam1
verbatim  

 [Query] Query 
Show which files in CWD have changed relative to the most recent
committed version in the Dust repository.
Then show precisely what has changed for file  'dstmbl.F'.
verbatim  
cvs -nq update -kk
verbatim  
The result of  'cvs -n update' is a list of files which differ
from the repository. 
Each file is prefixed by a code.
The most common codes are  'C' (for conflicts),  'M'
(local modifications newer than repository), and  'U' (local file
needs updating).
Conflicts 
verbatim  
/home/zender/f: cvs -n update
cvsbin update: Updating .
C Makefile
M csz f77.F
U sng.F
verbatim  
The precise differences relative to the repository are shown with
verbatim  
cvs diff -kk
verbatim  
Show which files in CWD have changed relative to version
 'mdl-1 0' in the CCM repository.
Then show precisely what has changed for file  'Makefile'.
verbatim  
cvs -nq update -r mdl-1 0 -kk
cvs diff -r mdl-1 0 -kk Makefile
verbatim  

 [Release] Release 
Release the current Dust module and check out a new working copy. 
verbatim  
# Above top-level of CWD
cvs -d /fs/cgd/csm/models/CVS.REPOS release -d ccm dst
cvs -d /fs/cgd/csm/models/CVS.REPOS co -r ccm brnch dst -kk ccm dst
verbatim  

 [Tag] Tag 
Note that tagging in the CCM repository invokes error checking modules
and, by default, launches windows which request one line summaries
on the local machine.
Attempting to tag from behind a firewall or proxy can thus result in 
failure because the windows are unable to open on the requested
console.
In this case, the tagging must be done from
  goldhill.cgd.ucar.edu , and the user's   DISPLAY  must be
set to  'NONE'
verbatim  
export DISPLAY=NONE
verbatim  
This problem does not arise when tagging from an unfiltered IP address.

Tag CWD with  'ccm3 6 brnchT dst1 2'. 
Option  '-c' causes  'tag' to verify that files beneath CWD
are not modified relative to the repository. 
This ensures the repository has all the information needed to exactly
reproduce the CWD from the tag name in the future.
verbatim  
cd ccm dst              # Move to top-level of CWD
cvs tag -c ccm3 6 brnchT dst1 2
verbatim  

 [Update] Update 
Update the CWD to a newer CCM version.
verbatim  
# Above top-level of CWD
cvs -d /fs/cgd/csm/models/CVS.REPOS co -r ccm brnch dst -kk ccm dst
cvs -d /fs/cgd/csm/models/CVS.REPOS diff -kk -r ccm3 5 22 ccm dst > pre.diff
cvs -d /fs/cgd/csm/models/CVS.REPOS update -j ccm3 5 22 -j ccm3 6 ccm dst
cvs -d /fs/cgd/csm/models/CVS.REPOS status ccm dst | grep -i conflict
cvs -d /fs/cgd/csm/models/CVS.REPOS diff -kk -r ccm3 6 ccm dst > post.diff
diff pre.diff post.diff > diff.diff
cvs commit ccm dst
cvs tag -c ccm3 6 brnchT dst1 0 ccm dst
verbatim  

  MATCH-Dust Module   sxn:cvs match dst 
The module  'match dst' comprises the sub-modules  'match' and
 'dst'. 
Thus  'match dst' is the complete MATCH with the dust modifications. 
Code modifications related to dust appear in the usual files in
 'src' (e.g., file  'physlic.F'). 
Most of the dust physics are isolated in new files in the  'dst'
directory, e.g.,  'dstmbl.F'.
The branch  'match dst-0' was created as a branch of MATCH
Spitfire version 3.2.9.
First, we defined module  'match dst' by editing the
 '/fs/cgd/csm/people/eaton/CVS/CVSROOT/modules' file to contain
the following lines: 
verbatim  
match           match
matchSrc        -d src match/src
matchReaders    -d readers match/readers
...
dst             dust
match dst       match &dst
verbatim  
The  'dust' source directory in the MATCH repository is actually a
symbolic link to the dust source in the CSM repository: 
verbatim  
cd /fs/cgd/csm/people/eaton/CVS
ln -s /fs/cgd/csm/models/CVS.REPOS/atm/ccm src dirs/dust .
verbatim  
Next, we added a MATCH tag to the CCM branch of the Dust module.
verbatim  
cvs -d /fs/cgd/csm/models/CVS.REPOS co -kk -r ccm brnch dst dst
cd dst
cvs tag -c MATCH SPITFIRE-3 2 9
verbatim  
This enabled us to check out both MATCH and Dust at the same time in
preparation for the next step, creating the MATCH-Dust branch.
Note that in order to apply MATCH tags to files in the CCM repository,
we had to disconnect the CCM-Dust module from the default CCM tag
syntax checking routines.
Finally, we created and tagged the MATCH-Dust branch.
verbatim  
cvs -d /fs/cgd/csm/people/eaton/CVS rtag -b -r MATCH SPITFIRE-3 2 9 

match brnch dst match dst
verbatim  
In the preceding command,  'MATCH SPITFIRE-3 2 9' is the
pre-existing tag associated with all files that were placed in the 
new  'match brnch dst' branch of the  'match dst' module.
Originally, we left the  'MATCH SPITFIRE-3 2 9' tag on the files
in the  'dst' directory, but this caused problems when merging
changes to the main trunk of the MATCH into MATCH-Dust.
The tag caused CVS to think that the Dust-specific files were parts of
 'MATCH SPITFIRE-3 2 9', and thus CVS tried to remove them when
updating to a later version on the main trunk.
Thus, we later removed the  'MATCH SPITFIRE-3 2 9' tag from all
the files in the  'dst' directory.

 [Repository changes] Changes to standard MATCH repository 
Once these commands were completed, we slightly altered the
architecture of the MATCH-Dust repository to facilitate CCM-style
compiling methods (i.e., compile from list of directories rather than
list of individual files plus directories).
 'match brnch dst' was created from the MATCH 3.2 repository,
and these commands were used to modify the standard MATCH repository:
verbatim  
# Routine to read CCM dynamics data conflicts with NCEP reader routine.
# Store it in parallel, non-conflicting, directory:
cd /fs/cgd/data0/zender/match dst/readers
mkdir ccm
cvs add ccm
cd ccm
mv /fs/cgd/data0/zender/match dst/src/dyninp.F .
cvs remove /fs/cgd/data0/zender/match dst/src/dyninp.F
cvs add dyninp.F

/bin/rm extoro.F setzen.F # Remove relics from Mark Lawrence
cvs remove extoro.F setzen.F
/bin/rm cloud dum.F # Routines superceded by prognostic cloud water
cvs remove cloud dum.F

cd ..
cvs commit -m "Rearranged files to work with MATCH-Dust Makefile"
verbatim  
To create a dust branch from the standard MATCH 4.X repository, the
following changes to the standard directory structure would be
required: 
verbatim  
# Routine to read CCM dynamics data conflicts with NCEP reader routine.
# Store it in parallel, non-conflicting, directory:
cd /fs/cgd/data0/zender/match dst/readers
mkdir ccm
cvs add ccm
cd ccm
mv /fs/cgd/data0/zender/match dst/src/dyninp.F .
cvs remove /fs/cgd/data0/zender/match dst/src/dyninp.F
cvs add dyninp.F

# Remove routines in libncaru.a and libmss.a on NCAR computers
/bin/rm setzen.F # Remove relics from Mark Lawrence
cvs remove setzen.F

cd ..
cvs commit -m "Rearranged files to work with MATCH-Dust Makefile"
verbatim  

 [Checkout] Checkout 
Checkout the latest version of the MATCH-Dust module. 
A  '-d' argument after the verb specifies an arbitrary directory
for the module.
verbatim  
# Get MATCH-Dust on Dataproc
cd /fs/cgd/data0/zender
cvs -d /fs/cgd/csm/people/eaton/CVS co -r match brnch dst -kk match dst
# Get MATCH-Dust in CGD
cvs -d :pserver:zender@goldhill.cgd.ucar.edu:/fs/cgd/csm/people/eaton/CVS 

co -r match brnch dst -kk match dst 
# Get MATCH-Dust at UCI
cvs -d :ext:zender@goldhill.cgd.ucar.edu:/fs/cgd/csm/people/eaton/CVS co -r match brnch dst -kk match dst 
# Get Dust box model at UCI (i.e., checkout the dst directory, name it aer)
cvs -d :ext:zender@goldhill.cgd.ucar.edu:/fs/cgd/csm/people/eaton/CVS co -r match brnch dst -kk -d aer dst
# Get Assimilation model at UCI
cvs -d :ext:zender@goldhill.cgd.ucar.edu:/fs/cgd/csm/people/eaton/CVS co -r match3 3 24 ind1 19 -kk -d  HOME /match asm match
cvs -d :ext:zender@goldhill.cgd.ucar.edu:/fs/cgd/csm/people/eaton/CVS co -r match3 3 24 ind1 19 -kk -d  HOME /match asm/dst dst
# Create Pat's branch
cvs -d :ext:zender@goldhill.cgd.ucar.edu:/fs/cgd/csm/people/eaton/CVS rtag -b -r match-3 3 23-dst-0 9 8 match brnch dst pjones match dst
# Checkout Pat's branch (``old'' model)
cvs -d :ext:zender@goldhill.cgd.ucar.edu:/fs/cgd/csm/people/eaton/CVS co -r match brnch dst pjones -kk -d match dst old match dst 
# Create Alf's sandblasting branch
cvs tag -b -r match-4 0 beta2-dst-1 1 1 match brnch dst sbl match dst
# Checkout Alf's sandblasting branch
cvs -d :ext:zender@goldhill.cgd.ucar.edu:/fs/cgd/csm/people/eaton/CVS co -r match brnch dst sbl -kk -d match dst sbl match dst 
# Get Dust box model from ESMF (i.e., model directory is named dead)
cvs -d :ext:zender@esmf.ess.uci.edu:/u/zender/cvs co -kk -r match brnch dst dead
verbatim  

 [Tag] Tag 
Tag CWD with  'match-3 2 10-dst-1 3'.
Option  '-c' causes  'tag' to verify that files beneath CWD
are not modified relative to the repository. 
This ensures the repository has all the information needed to exactly
reproduce the CWD from the tag name in the future.
Be sure this version compiles before tagging it.
verbatim  
cd match dst            # Move to top-level of CWD
cvs tag -c match-3 2 10-dst-1 3
verbatim  

 [Merge CCM into CCM-Dust] Merge CCM changes into CCM-Dust 
Merge changes to main CCM trunk into the CCM-Dust branch. 
Merging main trunk changes into CCM-Dust should never change the
 'dst' directory itself, but should alter the contents of
 'src/physics',  'src/control', etc. 
This example merges the changes from CCM version
 'ccm3 6' to CCM version
 'ccm3 6 6' into CCM-Dust version
 'ccm3 6 brnchT dst-0 9 6', which is then tagged as
 'ccm3 6 6 brnchT dst-0 9 6'. 
verbatim  
cd /fs/cgd/data0/zender/ccm dst
cvs diff -kk -r ccm3 6 > pre.diff
cvs update -kk -j ccm3 6 -j ccm3 6 6
cvs status | grep -i conflict
cvs diff -kk -r ccm3 6 6 > post.diff
diff pre.diff post.diff > diff.diff
make ccm
cvs commit 
cvs tag -c ccm3 6 6 brnchT dst-0 9 6
verbatim  

 [Merge MATCH into MATCH-Dust] Merge MATCH changes into MATCH-Dust 
Merge changes to main MATCH trunk into the MATCH-Dust branch. 
Merging main trunk changes into MATCH-Dust should never change the
 'dst' directory itself, but should alter the contents of
 'src',  'readers', etc. 
This example merges the changes from MATCH version
 'match3 2 10 scyc1 0' to MATCH version
 'match3 3 20' into MATCH-Dust version
 'match-3 2 10-dst-1 4a', which is then tagged as
 'match-3 3 20-dst-1 4a'. 
verbatim  
cd /fs/cgd/data0/zender/match dst
cvs diff -kk -r match3 2 10 scyc1 0 > pre.diff
cvs update -kk -j match3 2 10 scyc1 0 -j match3 3 20
cvs status | grep -i conflict
cvs diff -kk -r match3 3 20 > post.diff
diff pre.diff post.diff > diff.diff
make match
cvs commit 
cvs tag -c match-3 3 20-dst-1 4a
verbatim  

 [Merge MATCH-Dust into CCM-Dust] Merge MATCH-Dust changes into CCM-Dust 
Merge changes to the MATCH-Dust branch into the CCM-Dust branch. 
A simple ``  cvs update '' does not work because the changes are
on different branches.
This example merges the changes from MATCH-Dust version
 'match-3 2 9-dst-1 2' to MATCH-Dust version
 'match-3 2 10-dst-1 4' into CCM-Dust version
 'ccm3 6 brnchT dst1 2', which is then tagged as
 'ccm3 6 brnchT dst1 4'.  
verbatim  
cd /fs/cgd/data0/zender/ccm dst/src/dst
cvs diff -kk -r ccm3 6 brnchT dst1 2 > pre.diff
cvs update -kk -j match-3 2 9-dst-1 2 -j match-3 2 10-dst-1 4
cvs status | grep -i conflict
cvs diff -kk -r match-3 2 10-dst-1 4 > post.diff
diff pre.diff post.diff > diff.diff
make ccm
cvs commit 
cvs tag -c ccm3 6 brnchT dst1 4
verbatim  

 [Merge CCM-Dust into MATCH-Dust] Merge CCM-Dust changes into MATCH-Dust 
Merge changes to the CCM-Dust branch into the MATCH-Dust branch.  
A simple ``  cvs update '' does not work because the changes are
on different branches.
This example merges the changes from CCM-Dust version
 'match-3 2 9-dst-1 0' to CCM-Dust version
 'ccm3 6 brnchT dst1 2' into MATCH-Dust version
 'match-3 2 9-dst-1 0', which should then be tagged as
 'match-3 2 9-dst-1 2'. 
verbatim  
cd /fs/cgd/data0/zender/match dst/dst
cvs diff -kk -r match-3 2 9-dst-1 0 > pre.diff
cvs update -kk -j match-3 2 9-dst-1 0 -j ccm3 6 brnchT dst1 2
cvs update -p -j match-3 2 9-dst-1 0 params.h > params.h
cvs status | grep -i conflict
cvs diff -kk -r ccm3 6 brnchT dst1 2 > post.diff
diff pre.diff post.diff > diff.diff
cvs commit
make match
cvs tag -c match-3 2 9-dst-1 2
verbatim  

  MOZART-Dust Module   sxn:cvs mozart dst 
The module  'mozart dst' comprises the sub-modules  'mozart' and
 'dst'. 
Thus  'mozart dst' is the complete MOZART with the dust modifications. 
The MOZART Dust implementation was created well after MATCH-Dust, and
uses most of the same directory structure.
Thus, the CVS commands for manipulating the MOZART-Dust model are
directly analogous to those described in Section   sxn:cvs match dst ,
with the following exceptions.

 [Field names] Field names 
By default, MOZART archives both instantaneous values of constituents
mixing ratios. 
These are given the names assigned in the code, e.g.,  'DSTQ01'.
MOZART can also be told to archive time-averaged values of these
constituent fields.
Time-averaged constituent fields are assigned names based on there
constituent index in the model, e.g.,  'TRA01'.

  Subversion Overview   sxn:svn 

  Modules   sxn:svn mdl 
To create a   Subversion  repository, use
verbatim  
svnadmin create /home/zender/svn
verbatim  

  Generic Modules   sxn:svn gnr 

 [Import] Import an existing directory   sxn:cvs mpr 
The   cvs2svn  command converts CVS repositories to
  Subversion  repositories.
verbatim  
# Dry run do not actually commit anything.
cvs2svn -v --dry-run -s /home/zender/nco esmf.ess.uci.edu:/u/zender/cvs
cvs2svn -v --dry-run -s /home/zender/svn /home/zender/cvs
cvs2svn -v --dry-run -s /var/www/html/svn esmf.ess.uci.edu:/u/zender/cvs
# Commands actually used
cvs2svn -v --existing-svnrepos --force-tag=map-2 1 2 

        -s /home/zender/svn /home/zender/cvs
# Valid Subversion keywords are:
Date Revision Author HeadURL Id
By default cvs2svn expands CVS keywords Name, Revision, Header 
prior to importing to Subversion.
cvs2svn correctly transitions CVS keywords Date, Id to Subversion.
# Keyword expansion appears to be automatic: How to turn off?
cvs2svn --keywords-off
svn propset svn:keywords "Date Id" fff.F90
svn propset svn:keywords "Revision" fff.F90
# Find all files changed since 20081118
cvs diff -N -c -D 20081118 | grep "Index:" >  /foo.new
# Backup ESMF CVS
cd /home/zender
tar cvzf ./cvs.tar.gz ./cvs
scp cvs.tar.gz pbs.ess.uci.edu:
# Production conversion on PBS
/bin/rm -r -f  /svn
cvs2svn -v -s /home/zender/svn /home/zender/cvs >  /cvs2svn.txt
# keywords-off does not help me email from DLW 20081125
# cvs2svn --keywords-off -v -s /home/zender/svn /home/zender/cvs >  /cvs2svn.txt
# http://www.cvsnt.org/manual/html/Substitution-modes.html
# To switch off keyword substitution for all files in a subtree: 
cvs update -k +o
cvs commit -m "Change substitution mode"
verbatim  
Import new source directories:
verbatim  
svn help import
cd mdl
svn import -m "Imported sources"  /mdl file:///home/zender/svn
svn import -m "Imported sources"  /mdl http://dust.ess.uci.edu/svn
cd ..
mv mdl mdl.bck
cvs co -kk mdl
ls -R mdl
/bin/rm -r mdl.bck
verbatim  

Convert my CVS repositories from ESMF to PBS 20090205:
verbatim  
rps usr='zender/cvs'
#rps srv old='pbs'
#rps srv new='esmf'
rps srv old='esmf'
rps srv new='pbs'
export CVS RSH='ssh'    # Needed for ssh access to NCAR CGD CVS
export CVSROOT=":ext: USER @ rps srv new .ess.uci.edu:/home/ USER /cvs"
echo ":ext: rps srv new .ess.uci.edu:/home/zender/cvs" >  /cvs zender.txt
locate CVS/Root | grep zender >  /cvs Root.txt
for fl in `cat cvs Root.txt`; do
rps crr=`cat  fl `
case " rps crr " in 
    * rps srv * rps usr * ) 
    printf " fl  points to a  rps usr  repository on  rps srv old , will redirect to  rps srv new  "
    /bin/cp -f  /cvs zender.txt  fl 
    ;; # endif match*
    * )
    printf " fl  does not point to a  rps usr  repository on  rps srv old , will not change "
    ;; # endif default
esac # endcase  rps crr 
done
# Server instructions here were not helpful:
# http://sanatio.blogspot.com/2005/12/cvs-server-on-ubuntu.html
# Instead, had to manually create lock directories on server with
sudo mkdir /var/locks
sudo mkdir /var/locks/cvs
sudo chmod 777 /var/locks
sudo chmod 777 /var/locks/cvs
verbatim  

Check out modules:
verbatim  
svn checkout file:///home/zender/svn/trunk/f  /foo
svn checkout file:///home/zender/svn/trunk/mdl  /mdl
verbatim  
Examine status or working directory
verbatim  
svn status
verbatim  
Commit changes in working directory
verbatim  
svn 
verbatim  
List modules contained in repository
verbatim  
svn ls svn+ssh://zender@pbs.ess.uci.edu/home/zender/svn/trunk
svn checkout file:///home/zender/svn/trunk/dot  /dot
verbatim  

Converting CVS keywords to Subversion properties:
First, find the files with keywords, e.g., 
verbatim  
egrep -rl '$(Author|Date|Header|Name|Revision|Source|State|Id)' *
verbatim  
Determine the appropriate properties to set by searching
Subversion's hidden   .svn  directory, e.g.,
verbatim  
# Convert Id to Id keyword
perl -pi -e 's/$Header$/$Id$/g;' *
perl -pi -e 's/$Id/$Id$/g;' *
egrep -rl '$Id: ' * | grep -v /.svn/ | xargs svn propset svn:keywords Id
svn commit
verbatim  


document