/[MITgcm]/mitgcm.org/cvspolicy.html
ViewVC logotype

Contents of /mitgcm.org/cvspolicy.html

Parent Directory Parent Directory | Revision Log Revision Log | View Revision Graph Revision Graph


Revision 1.8 - (show annotations) (download) (as text)
Fri Feb 16 02:03:59 2001 UTC (20 years, 11 months ago) by adcroft
Branch: MAIN
Changes since 1.7: +10 -3 lines
File MIME type: text/html
Added title and title tag.

1 <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
2 <html>
3 <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>
9 <body text="#000000" bgcolor="#FF99FF" link="#0000EF" vlink="#51188E" alink="#FF0000">
10
11 <center>
12 <h1>
13 MITgcm CVS&nbsp;policy</h1></center>
14
15 <h2>
16 Introduction</h2>
17 This note describes policies that apply to the MITGCM CVS repository.
18 <h2>
19 Why have a policy?</h2>
20 CVS itself is a liberal free-for-all product that can be used in a variety
21 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.
23 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
25 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,
27 the task of finding a coherent collection of material soon becomes impossible.
28 <p>The policies we employ address two areas
29 <ol>
30 <li>
31 Maintaining an orderly and easily identifiable, coherent set of evolving
32 "products".</li>
33
34 <li>
35 Allowing concurrent, on-going development of product components.</li>
36 </ol>
37
38 <h2>
39 Development trees and checkpoint trees</h2>
40 A directory within the MITGCM repository resides under either the development
41 branch or the checkpoint branch. Files within each branch follow different
42 policies.
43 <h2>
44 Development tree policies</h2>
45 Development trees are intended to be flexible areas where arbitrary files
46 can be stored with multiple versions, many branches supporting multiple
47 ongoing streams of development. Development trees have no policies in place
48 to control complexity. Development trees might be associated with a particular
49 person, a certain project or a particular special piece of work. These
50 trees are intended to be useful areas for storing current work and for
51 archiving partially finished work so that it doesn't get mislaid and so
52 that some record of the development history can be easily maintained. The
53 only policy that applies to development trees is that this style of tree
54 is not intended to be used for providing a "checkpoint" distribution. Tagged
55 configurations of tools built from this style of tree can be distributed,
56 but because these trees do not have any polcies regarding testing of functionality,
57 platform coverage or documentation these trees are not allowed to form
58 the basis of "checkpoint" distrbutions or formal "releases". Other policies
59 can be defined by individuals users of these trees but there are no further
60 global policies. The MITGCM repository development_tree/ subdirectory is
61 reserved for holding development trees. Development trees also serve as
62 experimental areas for exploring new code management policies.
63 <h2>
64 Checkpoint tree policies</h2>
65 Checkpoint trees are intended to provide structured storage areas for holding
66 code that is intended for open distribution and is to be readily downloaded.
67 There are policies governing the operation of these trees which are designed
68 to ensure that distributed codes are early identified and meet certain
69 levels of quality.
70 <ol>
71 <li>
72 Check-out</li>
73
74 <br>Just do it! Two mechanisms are available. cvsanon for read only access
75 and regular cvs co .... for read/write access.
76 <li>
77 Check-in</li>
78
79 <br>The code check in procedure for a "checkpoint" tree is as follows
80 <ol>
81 <li>
82 Check out the latest main branch revision.</li>
83
84 <li>
85 Merge your changes into that revision.</li>
86
87 <li>
88 Build and validate new code.</li>
89
90 <li>
91 Check that there have been no further changes to the repository. Repeat
92 from 2.1 if repository has changed.</li>
93
94 <li>
95 Get clearance from other developers to check in your changes.</li>
96
97 <li>
98 Check in your changed main branch.</li>
99
100 <li>
101 Build and validate the new changes.</li>
102
103 <li>
104 Tag code as "checkpointNN". Add records to docs/tag-index.</li>
105
106 <li>
107 Build and validate test cases (see testing).</li>
108
109 <li>
110 Create and install checkpointNN.tar.gz</li>
111 </ol>
112
113 <li>
114 Testing</li>
115
116 <br>Things in a checkpoint tree require a test case that can be used to
117 validate the component.
118 <li>
119 Checkpoint tagging</li>
120
121 <br>No code should be left in limbo. Checking in code and then leaving
122 it in the repository untagged is bad. When you check in code you are creating
123 a new checkpoint. That means you don't check in some code which you "know"
124 works 100% and then go away for two weeks. When you start checking in code
125 you make sure you have time to do the process end-to-end as described in
126 section 2.
127 <li>
128 Release tagging</li>
129
130 <br>Releases are only based on checkpoint tree code. Maintenance fixes
131 to releases are also maintained within the checkpoint tree. Files within
132 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: 2001/02/16 02:00:47 $</font></td>
161
162 <td>
163 <div align=right><font size=-1>CVS: $Source: /u/gcmpack/mitgcm.org/../cvspolicy.html,v
164 $Revision: 1.7 $</font></div>
165 </td>
166 </tr>
167 </table>
168
169 </body>
170 </html>

  ViewVC Help
Powered by ViewVC 1.1.22