1 |
|
<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> |
2 |
<html> |
<html> |
3 |
<head> |
<head> |
4 |
|
<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]"> |
6 |
|
<meta name="Author" content="Chris Hill"> |
7 |
|
<title>MITgcm CVS policy</title> |
8 |
</head> |
</head> |
9 |
<body> |
<body text="#000000" bgcolor="#FF99FF" link="#0000EF" vlink="#51188E" alink="#FF0000"> |
10 |
MITGCM CVS policies |
|
11 |
=================== |
<center> |
12 |
|
<h1> |
13 |
o Introduction |
MITgcm CVS policy</h1></center> |
14 |
|
|
15 |
This note describes policies that apply to the MITGCM CVS repository |
<h2> |
16 |
|
Introduction</h2> |
17 |
o Why have a policy? |
This note describes policies that apply to the MITGCM CVS repository. |
18 |
|
<h2> |
19 |
CVS itself is a liberal free-for-all product that can be used in a variety |
Why have a policy?</h2> |
20 |
of ways. It is designed to provide a system for storing arbitrary files |
CVS itself is a liberal free-for-all product that can be used in a variety |
21 |
in a way that allows the change history of the individual files to be |
of ways. It is designed to provide a system for storing arbitrary files |
22 |
tracked. If CVS is used without any other policy the result can be a |
in a way that allows the change history of the individual files to be tracked. |
23 |
collection of files each of which has complex, multiply branched set of |
If CVS is used without any other policy the result can be a collection |
24 |
interelated versions. This sort of CVS repository can be come like a |
of files each of which has complex, multiply branched set of interelated |
25 |
library where books are simply stored in a huge heap. Although nothing is |
versions. This sort of CVS repository can be come like a library where |
26 |
actually lost, the task of finding a coherent collection of material soon |
books are simply stored in a huge heap. Although nothing is actually lost, |
27 |
becomes impossible. |
the task of finding a coherent collection of material soon becomes impossible. |
28 |
|
<p>The policies we employ address two areas |
29 |
The policies we employ address two areas |
<ol> |
30 |
1. Maintaining an orderly and easily identifiable, coherent set of |
<li> |
31 |
evolving "products". |
Maintaining an orderly and easily identifiable, coherent set of evolving |
32 |
2. Allowing concurrent, on-going development of product components. |
"products".</li> |
33 |
|
|
34 |
o Development trees and checkpoint trees |
<li> |
35 |
|
Allowing concurrent, on-going development of product components.</li> |
36 |
A directory within the MITGCM repository resides under either the |
</ol> |
37 |
development branch or the checkpoint branch. Files within each branch |
|
38 |
follow different policies. |
<h2> |
39 |
|
Development trees and checkpoint trees</h2> |
40 |
o Development tree policies |
A directory within the MITGCM repository resides under either the development |
41 |
|
branch or the checkpoint branch. Files within each branch follow different |
42 |
Development trees are intended to be flexible areas where arbitrary files |
policies. |
43 |
can be stored with multiple versions, many branches supporting multiple |
<h2> |
44 |
ongoing streams of development. Development trees have no policies in |
Development tree policies</h2> |
45 |
place to control complexity. Development trees might be associated with |
Development trees are intended to be flexible areas where arbitrary files |
46 |
a particular person, a certain project or a particular special piece of |
can be stored with multiple versions, many branches supporting multiple |
47 |
work. These trees are intended to be useful areas for storing current |
ongoing streams of development. Development trees have no policies in place |
48 |
work and for archiving partially finished work so that it doesn't get |
to control complexity. Development trees might be associated with a particular |
49 |
mislaid and so that some record of the development history can be easily |
person, a certain project or a particular special piece of work. These |
50 |
maintained. The only policy that applies to development trees is that |
trees are intended to be useful areas for storing current work and for |
51 |
this style of tree is not intended to be used for providing a |
archiving partially finished work so that it doesn't get mislaid and so |
52 |
"checkpoint" distribution. Tagged configurations of tools built from this |
that some record of the development history can be easily maintained. The |
53 |
style of tree can be distributed, but because these trees do not have any |
only policy that applies to development trees is that this style of tree |
54 |
polcies regarding testing of functionality, platform coverage or |
is not intended to be used for providing a "checkpoint" distribution. Tagged |
55 |
documentation these trees are not allowed to form the basis of |
configurations of tools built from this style of tree can be distributed, |
56 |
"checkpoint" distrbutions or formal "releases". Other policies can |
but because these trees do not have any polcies regarding testing of functionality, |
57 |
be defined by individuals users of these trees but there are no further |
platform coverage or documentation these trees are not allowed to form |
58 |
global policies. The MITGCM repository development_tree/ subdirectory is |
the basis of "checkpoint" distrbutions or formal "releases". Other policies |
59 |
reserved for holding development trees. Development trees also serve as |
can be defined by individuals users of these trees but there are no further |
60 |
experimental areas for exploring new code management policies. |
global policies. The MITGCM repository development_tree/ subdirectory is |
61 |
|
reserved for holding development trees. Development trees also serve as |
62 |
o Checkpoint tree policies |
experimental areas for exploring new code management policies. |
63 |
|
<h2> |
64 |
Checkpoint trees are intended to provide structured storage areas for |
Checkpoint tree policies</h2> |
65 |
holding code that is intended for open distribution and is to be readily |
Checkpoint trees are intended to provide structured storage areas for holding |
66 |
downloaded. There are policies governing the operation of these trees |
code that is intended for open distribution and is to be readily downloaded. |
67 |
which are designed to ensure that distributed codes are clearly |
There are policies governing the operation of these trees which are designed |
68 |
identified and meet certain levels of quality. |
to ensure that distributed codes are early identified and meet certain |
69 |
|
levels of quality. |
70 |
1. Check-out |
<ol> |
71 |
|
<li> |
72 |
Just do it! Two mechanisms are available. cvsanon for read only access |
Check-out</li> |
73 |
and regular cvs co .... for read/write access. |
|
74 |
|
<br>Just do it! Two mechanisms are available. cvsanon for read only access |
75 |
2. Check-in. |
and regular cvs co .... for read/write access. |
76 |
|
<li> |
77 |
The code check in procedure for a "checkpoint" tree is as follows |
Check-in</li> |
78 |
2.1 Check out the latest main branch revision. |
|
79 |
2.2 Merge your changes into that revision. |
<br>The code check in procedure for a "checkpoint" tree is as follows |
80 |
2.3 Build and validate new code. |
<ol> |
81 |
2.4 Check that there have been no further changes to the |
<li> |
82 |
repository. Repeat from 2.1 if repository has changed. |
Check out the latest main branch revision.</li> |
83 |
2.5 Get clearance from other developers to check in your changes. |
|
84 |
2.6 Check in your changed main branch. |
<li> |
85 |
2.8 Build and validate the new changes. |
Merge your changes into that revision.</li> |
86 |
2.9 Tag code as "checkpointNN". Add records to docs/tag-index. |
|
87 |
2.10 Build and validate test cases (see testing). |
<li> |
88 |
2.11 Create and install checkpointNN.tar.gz |
Build and validate new code.</li> |
89 |
|
|
90 |
3. Testing |
<li> |
91 |
|
Check that there have been no further changes to the repository. Repeat |
92 |
Things in a checkpoint tree require a test case that |
from 2.1 if repository has changed.</li> |
93 |
can be used to validate the component. |
|
94 |
|
<li> |
95 |
4. Checkpoint tagging |
Get clearance from other developers to check in your changes.</li> |
96 |
|
|
97 |
No code should be left in limbo. Checking in code and then |
<li> |
98 |
leaving it in the repository untagged is bad. When you check |
Check in your changed main branch.</li> |
99 |
in code you are creating a new checkpoint. That means you don't |
|
100 |
check in some code which you "know" works 100% and then go away |
<li> |
101 |
for two weeks. When you start checking in code you make sure |
Build and validate the new changes.</li> |
102 |
you have time to do the process end-to-end as described in section |
|
103 |
2. |
<li> |
104 |
|
Tag code as "checkpointNN". Add records to docs/tag-index.</li> |
105 |
5. Release tagging |
|
106 |
|
<li> |
107 |
Releases are only based on checkpoint tree code. Maintenance fixes |
Build and validate test cases (see testing).</li> |
108 |
to releases are also maintained within the checkpoint tree. Files |
|
109 |
within a release must have accompanying documentation. The form of this |
<li> |
110 |
documentation depends on the file type. |
Create and install checkpointNN.tar.gz</li> |
111 |
|
</ol> |
112 |
6. Branches |
|
113 |
|
<li> |
114 |
Branches are to be used for bug-fixes and code patches to releases |
Testing</li> |
115 |
only. All other changes e.g. totally new features, bug-fixes to |
|
116 |
checkpoints are introduced by moving checkpoint levels forward. The |
<br>Things in a checkpoint tree require a test case that can be used to |
117 |
only historical code maintenance that is employed is for fixes and |
validate the component. |
118 |
patches to formal releases - not checkpoints. |
<li> |
119 |
|
Checkpoint tagging</li> |
120 |
o These policies are causing me a big problem, what can I do? |
|
121 |
|
<br>No code should be left in limbo. Checking in code and then leaving |
122 |
The policies are not enforced by any mechanism other than mutual |
it in the repository untagged is bad. When you check in code you are creating |
123 |
agreement! If you think the policies are not appropriate then let us know |
a new checkpoint. That means you don't check in some code which you "know" |
124 |
and we can discuss changing them. However, if you simply ignore the |
works 100% and then go away for two weeks. When you start checking in code |
125 |
policies regarding the checkpoint_release trees then your code may be |
you make sure you have time to do the process end-to-end as described in |
126 |
removed and/or your access revoked. |
section 2. |
127 |
|
<li> |
128 |
o What about bitkeeper |
Release tagging</li> |
129 |
|
|
130 |
We are looking at bitkeeper (www.bitkeeper.com). It looks cool, but |
<br>Releases are only based on checkpoint tree code. Maintenance fixes |
131 |
policies are still important. Any experience, suggestions let us know. |
to releases are also maintained within the checkpoint tree. Files within |
132 |
Watch this space! |
a release must have accompanying documentation. The form of this documentation |
133 |
|
depends on the file type. |
134 |
|
<li> |
135 |
|
Branches</li> |
136 |
|
|
137 |
|
<br>Branches are to be used for bug-fixes and code patches to releases |
138 |
|
only. All other changes e.g. totally new features, bug-fixes to checkpoints |
139 |
|
are introduced by moving checkpoint levels forward. The only historical |
140 |
|
code maintenance that is employed is for fixes and patches to formal releases |
141 |
|
- not checkpoints.</ol> |
142 |
|
|
143 |
|
<h2> |
144 |
|
These policies are causing me a big problem, what can I do?</h2> |
145 |
|
The policies are not enforced by any mechanism other than mutual agreement! |
146 |
|
If you think the policies are not appropriate then let us know and we can |
147 |
|
discuss changing them. However, if you simply ignore the policies regarding |
148 |
|
the checkpoint_release trees then your code may be removed and/or your |
149 |
|
access revoked. |
150 |
|
<h2> |
151 |
|
What about bitkeeper</h2> |
152 |
|
We are looking at bitkeeper (www.bitkeeper.com). It looks cool, but policies |
153 |
|
are still important. Any experience, suggestions let us know. Watch this |
154 |
|
space! |
155 |
|
<p>Questions, comments e-mail: code.czars@mitgcm.org |
156 |
|
<br> |
157 |
|
<hr WIDTH="100%"> |
158 |
|
<table CELLSPACING=0 CELLPADDING=0 WIDTH="100%" NOSAVE > |
159 |
|
<tr NOSAVE> |
160 |
|
<td><font size=-1>Last modified on $Date$</font></td> |
161 |
|
|
162 |
|
<td> |
163 |
|
<div align=right><font size=-1>CVS: /u/gcmpack/mitgcm.org/../cvspolicy.html,v |
164 |
|
$Revision$</font></div> |
165 |
|
</td> |
166 |
|
</tr> |
167 |
|
</table> |
168 |
|
|
|
Questions, comments e-mail: code.czars@mitgcm.org |
|
169 |
</body> |
</body> |
170 |
</html> |
</html> |