| 2 |
<html> |
<html> |
| 3 |
<head> |
<head> |
| 4 |
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> |
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> |
| 5 |
<meta name="GENERATOR" content="Mozilla/4.75 [en] (X11; U; Linux 2.2.14-5.0 i686) [Netscape]"> |
<meta name="GENERATOR" content="Mozilla/4.76 [en] (X11; U; Linux 2.4.1 i686) [Netscape]"> |
| 6 |
<meta name="Author" content="Chris Hill"> |
<meta name="Author" content="Chris Hill"> |
| 7 |
<title>MITgcm CVS policy</title> |
<title>MITgcm CVS policy</title> |
| 8 |
</head> |
</head> |
| 10 |
|
|
| 11 |
<center> |
<center> |
| 12 |
<h1> |
<h1> |
| 13 |
MITgcm CVS policy</h1></center> |
MITgcm CVS policy</h1></center> |
| 14 |
|
|
| 15 |
<h2> |
<h2> |
| 16 |
Introduction</h2> |
Introduction</h2> |
| 21 |
of ways. It is designed to provide a system for storing arbitrary files |
of ways. It is designed to provide a system for storing arbitrary files |
| 22 |
in a way that allows the change history of the individual files to be tracked. |
in a way that allows the change history of the individual files to be tracked. |
| 23 |
If CVS is used without any other policy the result can be a collection |
If CVS is used without any other policy the result can be a collection |
| 24 |
of files each of which has complex, multiply branched set of interelated |
of files each of which has complex, multiply branched set of inter-related |
| 25 |
versions. This sort of CVS repository can be come like a library where |
versions. This sort of CVS repository can be come like a library where |
| 26 |
books are simply stored in a huge heap. Although nothing is actually lost, |
books are simply stored in a huge heap. Although nothing is actually lost, |
| 27 |
the task of finding a coherent collection of material soon becomes impossible. |
the task of finding a coherent collection of material soon becomes impossible. |
| 28 |
<p>The policies we employ address two areas |
<p>The policies we employ address tree areas |
| 29 |
<ol> |
<ol> |
| 30 |
<li> |
<li> |
| 31 |
Maintaining an orderly and easily identifiable, coherent set of evolving |
Maintaining an orderly and easily identifiable, coherent set of evolving |
| 33 |
|
|
| 34 |
<li> |
<li> |
| 35 |
Allowing concurrent, on-going development of product components.</li> |
Allowing concurrent, on-going development of product components.</li> |
| 36 |
|
|
| 37 |
|
<li> |
| 38 |
|
Making the integration of achieved developments easy, rapid, organized |
| 39 |
|
and clear.</li> |
| 40 |
</ol> |
</ol> |
| 41 |
|
|
| 42 |
<h2> |
<h2> |
| 57 |
only policy that applies to development trees is that this style of tree |
only policy that applies to development trees is that this style of tree |
| 58 |
is not intended to be used for providing a "checkpoint" distribution. Tagged |
is not intended to be used for providing a "checkpoint" distribution. Tagged |
| 59 |
configurations of tools built from this style of tree can be distributed, |
configurations of tools built from this style of tree can be distributed, |
| 60 |
but because these trees do not have any polcies regarding testing of functionality, |
but because these trees do not have any policies regarding testing of functionality, |
| 61 |
platform coverage or documentation these trees are not allowed to form |
platform coverage or documentation these trees are not allowed to form |
| 62 |
the basis of "checkpoint" distrbutions or formal "releases". Other policies |
the basis of "checkpoint" distributions or formal "releases". Other policies |
| 63 |
can be defined by individuals users of these trees but there are no further |
can be defined by individuals users of these trees but there are no further |
| 64 |
global policies. The MITGCM repository development_tree/ subdirectory is |
global policies. The MITGCM repository development_tree/ sub-directory |
| 65 |
reserved for holding development trees. Development trees also serve as |
is reserved for holding development trees. Development trees also serve |
| 66 |
experimental areas for exploring new code management policies. |
as experimental areas for exploring new code management policies. |
| 67 |
<h2> |
<h2> |
| 68 |
Checkpoint tree policies</h2> |
Checkpoint tree policies</h2> |
| 69 |
Checkpoint trees are intended to provide structured storage areas for holding |
Checkpoint trees are intended to provide structured storage areas for holding |
| 122 |
<li> |
<li> |
| 123 |
Checkpoint tagging</li> |
Checkpoint tagging</li> |
| 124 |
|
|
| 125 |
<br>No code should be left in limbo. Checking in code and then leaving |
<br>No code should be left in limbo (un-tagged) for extended periods. On |
| 126 |
it in the repository untagged is bad. When you check in code you are creating |
the other hand it's unnecessary to create a checkpoint tag for every little |
| 127 |
a new checkpoint. That means you don't check in some code which you "know" |
change. Checkpoint tags should be made after a particularly significant |
| 128 |
works 100% and then go away for two weeks. When you start checking in code |
code modification or otherwise on a regular basis, say bi-weekly. Very |
| 129 |
you make sure you have time to do the process end-to-end as described in |
often we set a list of goals to be reached by the next checkpoint which |
| 130 |
section 2. |
sometimes takes more than two weeks to achieve. Obviously, in this case |
| 131 |
|
a bi-weekly checkpoint would not be useful. |
| 132 |
<li> |
<li> |
| 133 |
Release tagging</li> |
Release tagging</li> |
| 134 |
|
|
| 139 |
<li> |
<li> |
| 140 |
Branches</li> |
Branches</li> |
| 141 |
|
|
| 142 |
<br>Branches are to be used for bug-fixes and code patches to releases |
<br>Branches are a useful tool for making changes prior to checkpoints |
| 143 |
only. All other changes e.g. totally new features, bug-fixes to checkpoints |
without breaking other working versions but it must be understood that |
| 144 |
are introduced by moving checkpoint levels forward. The only historical |
branches are short-lived and that releases and checkpoints not be made |
| 145 |
code maintenance that is employed is for fixes and patches to formal releases |
from a branch. Branches are especially useful for adding totally |
| 146 |
- not checkpoints.</ol> |
<br>new features. bug-fixes to checkpoints are introduced by moving checkpoint |
| 147 |
|
levels forward. The only historical code maintenance that s employed is |
| 148 |
|
for fixes and patches to formal releases - not checkpoints.</ol> |
| 149 |
|
|
| 150 |
|
<h1> |
| 151 |
|
Someone checked-in broken code so not my code doesn't work?</h1> |
| 152 |
|
You have several options: |
| 153 |
|
<ol> |
| 154 |
|
<li> |
| 155 |
|
Politely email everyone at support@mitgcm.org asking what has happened |
| 156 |
|
and that it be fixed?</li> |
| 157 |
|
|
| 158 |
|
<li> |
| 159 |
|
Figure out why the new code is broken, fix it, check it in and proudly |
| 160 |
|
send a message to support@mitgcm.org to show how constructive you are.</li> |
| 161 |
|
|
| 162 |
|
<li> |
| 163 |
|
Complain that the quality of work is too low and then do nothing to fix |
| 164 |
|
the code.<br> |
| 165 |
|
<BR></li> |
| 166 |
|
|
| 167 |
|
<br>We advise you to only use the third option if you are confident that |
| 168 |
|
your own contributions to the code are bug-free, well written, documented |
| 169 |
|
and fool proof. :)</ol> |
| 170 |
|
|
| 171 |
<h2> |
<h2> |
| 172 |
These policies are causing me a big problem, what can I do?</h2> |
These policies are causing me a big problem, what can I do?</h2> |
Parent Directory
| 
Revision Log
| 
Revision Graph
| 
Patch