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

Annotation of /mitgcm.org/cvspolicy.html

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


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

1 adcroft 1.7 <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
2 cnh 1.2 <html>
3     <head>
4 adcroft 1.7 <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 adcroft 1.8 <meta name="Author" content="Chris Hill">
7     <title>MITgcm CVS policy</title>
8 cnh 1.2 </head>
9 adcroft 1.8 <body text="#000000" bgcolor="#FF99FF" link="#0000EF" vlink="#51188E" alink="#FF0000">
10    
11     <center>
12     <h1>
13     MITgcm CVS&nbsp;policy</h1></center>
14 cnh 1.1
15 adcroft 1.7 <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 adcroft 1.8 <td><font size=-1>Last modified on $Date: 2001/02/16 02:00:47 $</font></td>
161 adcroft 1.7
162     <td>
163 adcroft 1.8 <div align=right><font size=-1>CVS: $Source: /u/gcmpack/mitgcm.org/../cvspolicy.html,v
164     $Revision: 1.7 $</font></div>
165 adcroft 1.7 </td>
166     </tr>
167     </table>
168 cnh 1.1
169 cnh 1.2 </body>
170     </html>

  ViewVC Help
Powered by ViewVC 1.1.22