| 1 |
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" |
| 2 |
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> |
| 3 |
|
| 4 |
<html xmlns="http://www.w3.org/1999/xhtml"> |
| 5 |
<head> |
| 6 |
<meta name="generator" content="HTML Tidy, see www.w3.org" /> |
| 7 |
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" /> |
| 8 |
<base href="http:/mitgcm.org" /> |
| 9 |
|
| 10 |
<!-- Hinting for menu generation --> |
| 11 |
<meta name="add_name_0" content="Source Code" /> |
| 12 |
<meta name="add_name_1" content="Using CVS" /> |
| 13 |
<meta name="add_name_2" content="" /> |
| 14 |
<meta name="add_title" content="Using CVS" /> |
| 15 |
<!-- Hinting for menu generation --> |
| 16 |
|
| 17 |
<style type="text/css"> |
| 18 |
span.c2 {font-size: 110%} |
| 19 |
div.c1 {text-align: center} |
| 20 |
</style> |
| 21 |
</head> |
| 22 |
|
| 23 |
<body> |
| 24 |
|
| 25 |
<center> |
| 26 |
<h3>Obtaining the MITgcm Source using CVS</h3> |
| 27 |
</center> |
| 28 |
|
| 29 |
<h4>Using CVS "pserver" for Anonymous Access</h4> |
| 30 |
|
| 31 |
<p>The most convenient way to get local copies of the MITgcm source code is |
| 32 |
to use the CVS "pserver" mechanism. This method only allows you to "check |
| 33 |
out" (or obtain a local copy) of the source. It does not provide a |
| 34 |
mechanism for "committing" or "checking in" changes (please see below). |
| 35 |
Using CVS pserver from the command line requires just a three commands. |
| 36 |
Using a Bourne, "bash", or "sh-compatible" shell they are:</p> |
| 37 |
|
| 38 |
<pre> |
| 39 |
$ export CVSROOT=':pserver:cvsanon@mitgcm.org:/u/gcmpack' |
| 40 |
$ cvs login |
| 41 |
( enter the CVS password: "cvsanon" ) |
| 42 |
$ cvs co MITgcm MITgcm_contrib |
| 43 |
</pre> |
| 44 |
|
| 45 |
<p>Using a "C", "csh", or "tcsh" shell the commands are:</p> |
| 46 |
|
| 47 |
<pre> |
| 48 |
$ setenv CVSROOT ':pserver:cvsanon@mitgcm.org:/u/gcmpack' |
| 49 |
$ cvs login |
| 50 |
( enter the CVS password: "cvsanon" ) |
| 51 |
$ cvs co MITgcm MITgcm_contrib |
| 52 |
</pre> |
| 53 |
|
| 54 |
<p>Note that you will only need to perform the "cvs login" once. And for |
| 55 |
convenience, you may want to add the CVSROOT variable to your shell's |
| 56 |
environment (that is, define it within your "~/.bashrc" or "~/.chsrc" |
| 57 |
files).</p> |
| 58 |
|
| 59 |
|
| 60 |
<h4>Getting Parts of the Source "Tree"</h4> |
| 61 |
|
| 62 |
<p>The above commands demonstrate how to check out all of the MITgcm code |
| 63 |
and the "contributed" (that is, unsupported by often useful) information |
| 64 |
within the "MITgcm_contrib" directory. In many cases, this is overkill |
| 65 |
and can result in long download times. To reduce the volume of |
| 66 |
information downloaded and thereby speedup the download times, one can |
| 67 |
select one of the following pre-defined "aliases" that will provide a |
| 68 |
sub-set of the entire MITgcm source "tree":</p> |
| 69 |
|
| 70 |
<table align="center" border="0" cellpadding="10" width="90%" summary="CVS |
| 71 |
aliases"> |
| 72 |
<tr bgcolor="#00cccc"> |
| 73 |
<td width="25%">Alias Name</td> |
| 74 |
<td>Information (directories) Contained</td> |
| 75 |
</tr> |
| 76 |
<tr bgcolor="#bbffdd"> |
| 77 |
<td width="25%">MITgcm_code</td> |
| 78 |
<td>Only the source code -- none of the verification examples.</td> |
| 79 |
</tr> |
| 80 |
<tr bgcolor="#bbddff"> |
| 81 |
<td width="25%">MITgcm_verif_basic</td> |
| 82 |
<td>Source code plus a small set of the verification examples |
| 83 |
("global_ocean.90x40x15", "aim.5l_cs", "hs94.128x64x5", |
| 84 |
"front_relax", and "plume_on_slope").</td> |
| 85 |
</tr> |
| 86 |
<tr bgcolor="#bbffdd"> |
| 87 |
<td width="25%">MITgcm_verif_atmos</td> |
| 88 |
<td>Source code plus all of the atmospheric examples.</td> |
| 89 |
</tr> |
| 90 |
<tr bgcolor="#bbddff"> |
| 91 |
<td width="25%">MITgcm_verif_ocean</td> |
| 92 |
<td>Source code plus all of the oceanic examples.</td> |
| 93 |
</tr> |
| 94 |
<tr bgcolor="#bbffdd"> |
| 95 |
<td width="25%">MITgcm_verif_all</td> |
| 96 |
<td>Source code plus all of the verification examples.</td> |
| 97 |
</tr> |
| 98 |
<!-- |
| 99 |
<tr bgcolor="#bbddff"> |
| 100 |
<td width="25%"></td> |
| 101 |
<td></td> |
| 102 |
</tr> |
| 103 |
<tr bgcolor="#bbffdd"> |
| 104 |
<td width="25%"></td> |
| 105 |
<td></td> |
| 106 |
</tr> |
| 107 |
--> |
| 108 |
</table> |
| 109 |
|
| 110 |
|
| 111 |
<h4>Getting Specific Releases or "Checkpoints"</h4> |
| 112 |
|
| 113 |
<p>As shown within the <a |
| 114 |
href="http://dev.mitgcm.org/cgi-bin/viewcvs.cgi/MITgcm/doc/tag-index"> CVS |
| 115 |
Code Browser</a>, the MITgcm code is continuously undergoing updates. At |
| 116 |
points during the development (typically, after work has been done and the |
| 117 |
source code has passed the <a href="testing/latest.html">verification |
| 118 |
tests</a>), a release or checkpoint "tag" is created. These tags are a |
| 119 |
convenient mechanism for referring to different times or points within the |
| 120 |
development. One can check out these versions using the "-r TAG_NAME" CVS |
| 121 |
option such as: </p> |
| 122 |
|
| 123 |
<pre> |
| 124 |
$ cvs co -r release1_p5 MITgcm |
| 125 |
$ cvs co -r checkpoint52a_post MITgcm |
| 126 |
</pre> |
| 127 |
|
| 128 |
<p>By default (that is, when no tag is specified), CVS will retrieve the |
| 129 |
latest version of all files.</p> |
| 130 |
|
| 131 |
|
| 132 |
<h4>Show changes that YOU have made</h4> |
| 133 |
|
| 134 |
<p>If you are running into difficulties it is very useful to see the changes |
| 135 |
that you yourself have made since obtaining the code. From within |
| 136 |
your working directory:</p> |
| 137 |
|
| 138 |
<pre> |
| 139 |
cvs diff |
| 140 |
</pre> |
| 141 |
|
| 142 |
|
| 143 |
<p>will show the differences between your version and the version that you |
| 144 |
checked out. It acts recursively on all directories below your current |
| 145 |
directory. You can limit the operation to just one file or directory by |
| 146 |
specifying those as arguments:</p> |
| 147 |
|
| 148 |
<pre> |
| 149 |
cvs diff <i>file</i> |
| 150 |
</pre> |
| 151 |
|
| 152 |
|
| 153 |
<h4>Show changes to the repository that you don't have</h4> |
| 154 |
|
| 155 |
<p>The source code evolves continuously and you should try to stay up to |
| 156 |
date. To see what needs to be updated:</p> |
| 157 |
|
| 158 |
<pre> |
| 159 |
cvs -n update |
| 160 |
</pre> |
| 161 |
|
| 162 |
<p>behaves just as "cvs update" but doesn't actually change anything. This |
| 163 |
is a useful way of summarizing the state of your code. The meaning of the |
| 164 |
output is summarized in the next topic.</p> |
| 165 |
|
| 166 |
<h4>Getting updates from the repository</h4> |
| 167 |
|
| 168 |
<p>You can download and merge updates from the repository to bring you |
| 169 |
working code up to date:</p> |
| 170 |
|
| 171 |
<pre> |
| 172 |
cvs update -d -P |
| 173 |
</pre> |
| 174 |
|
| 175 |
<p>will work recursively on all files in the current directory and below. |
| 176 |
To update just a specific file or directory:</p> |
| 177 |
|
| 178 |
<pre> |
| 179 |
cvs update <i>file</i> |
| 180 |
</pre> |
| 181 |
|
| 182 |
<p>You can also update to a specific version, just as you could check out |
| 183 |
a specific version.</p> |
| 184 |
|
| 185 |
<pre> |
| 186 |
cvs update -d -P -r release1_p5 |
| 187 |
</pre> |
| 188 |
|
| 189 |
<p>If you checked out a specific version and want to update to the very |
| 190 |
latest use the -A option will remove associated with a specific version as |
| 191 |
follows:</p> |
| 192 |
|
| 193 |
<pre> |
| 194 |
cvs update -d -P -A |
| 195 |
</pre> |
| 196 |
|
| 197 |
<p>"cvs update" produces output to the terminal with the following |
| 198 |
meanings:</p> |
| 199 |
|
| 200 |
<table align="center" border="0" cellpadding="10" width="90%" summary="CVS |
| 201 |
update codes"> |
| 202 |
<tr bgcolor="#00cccc"> |
| 203 |
<td width="20%">Return Code</td> |
| 204 |
<td>Description</td> |
| 205 |
</tr> |
| 206 |
<tr bgcolor="#bbffdd"> |
| 207 |
<td width="20%">U <i>file</i></td> |
| 208 |
<td>indicates that <i>file</i> was brought up to date with the |
| 209 |
repository or that it exists in the repository but not in your work |
| 210 |
space</td> |
| 211 |
</tr> |
| 212 |
<tr bgcolor="#bbddff"> |
| 213 |
<td width="20%">P <i>file</td> |
| 214 |
<td>does exactly as above but uses the "patch" method</td> |
| 215 |
</tr> |
| 216 |
<tr bgcolor="#bbffdd"> |
| 217 |
<td width="20%">M <i>file</i></td> |
| 218 |
<td>means the <i>file</i> was modified in your work space. Any |
| 219 |
additional changes from the repository were merged in |
| 220 |
successfully</td> |
| 221 |
</tr> |
| 222 |
</tr> |
| 223 |
<tr bgcolor="#bbddff"> |
| 224 |
<td width="20%">C <i>file</i></td> |
| 225 |
<td>means a merge is necessary because both the your copy and the |
| 226 |
repository have changed <b>but</b> there is a conflict between the |
| 227 |
changes</td> |
| 228 |
</tr> |
| 229 |
<tr bgcolor="#bbffdd"> |
| 230 |
<td width="20%">? <i>file</i></td> |
| 231 |
<td>means the file exists in your work space but not on the |
| 232 |
repository</td> |
| 233 |
</tr> |
| 234 |
</table> |
| 235 |
|
| 236 |
<p>When conflicts arise, the sections of code are both kept and surrounded |
| 237 |
by <<<<<, ===== and >>>>> indicators. You need to examine |
| 238 |
these lines of the files and resolve the conflict.</p> |
| 239 |
|
| 240 |
<h4>Wow! CVS is so good, where can I learn more?</h4> |
| 241 |
|
| 242 |
<p>The <a href="http://www.loria.fr/~molli/cvs/doc/cvs_toc.html">basic |
| 243 |
manual</a> is a good reference. There is also an <a |
| 244 |
href="http://web.mit.edu/afs/athena.mit.edu/project/gnu/doc/html/cvs_toc.html">online |
| 245 |
tutorial</a> as well as an <a |
| 246 |
href="http://www.loria.fr/~molli/cvs/cvstrain/cvstrain.html">training |
| 247 |
manual</a>. For those who prefer the good old fashioned book there's <a |
| 248 |
href="http://cvsbook.red-bean.com/">"Open Source Development With |
| 249 |
CVS"</a>.</p> |
| 250 |
|
| 251 |
</body> |
| 252 |
</html> |
| 253 |
|
Parent Directory
| 
Revision Log
| 
Revision Graph