1 |
cnh |
1.1 |
GCMPACK CVS policies |
2 |
|
|
==================== |
3 |
|
|
|
4 |
|
|
o Introduction |
5 |
|
|
|
6 |
|
|
This note describes policies that apply to the GCMPACK CVS repository |
7 |
|
|
|
8 |
|
|
o Why have a policy? |
9 |
|
|
|
10 |
|
|
CVS itself is a liberal free-for-all product that can be used in a variety |
11 |
|
|
of ways. It is designed to provide a system for storing arbitrary files |
12 |
|
|
in a way that allows the change history of the individual files to be |
13 |
|
|
tracked. If CVS is used without any other policy the result can be a |
14 |
|
|
collection of files each of which has complex, multiply branched set of |
15 |
|
|
interelated versions. This sort of CVS repository can be come like a |
16 |
|
|
library where books are simply stored in a huge heap. Although nothing is actually lost, the task of finding a coherent collection of material soon |
17 |
|
|
becomes impossible. |
18 |
|
|
|
19 |
|
|
The policies we employ address two areas |
20 |
|
|
1. Maintaining an orderly and easily identifiable, coherent set of |
21 |
|
|
evolving "products". |
22 |
|
|
2. Allowing concurrent, on-going development of products. |
23 |
|
|
|
24 |
|
|
o Development trees and checkpoint trees |
25 |
|
|
|
26 |
|
|
A directory within the GCMPACK repository resides under either the |
27 |
|
|
development branch or the checkpoint branch. Files within each branch |
28 |
|
|
follow different policies. |
29 |
|
|
|
30 |
|
|
o Development tree policies |
31 |
|
|
|
32 |
|
|
Development trees are intended to be flexible areas where arbitrary files |
33 |
|
|
can be stored with multiple versions, many branches supporting multiple |
34 |
|
|
ongoing streams of development. Development trees have no policies in |
35 |
|
|
place to control complexity. Development trees might be associated with |
36 |
|
|
a particular person, a certain project or a particular special piece of |
37 |
|
|
work. These trees are intended to be useful areas for storing current |
38 |
|
|
work and for archiving partially finished work so that it doesn't get |
39 |
|
|
mislaid and s that some record of the development history can be easily |
40 |
|
|
maintained. The only policy that applies to development trees is that |
41 |
|
|
this style of tree is not intended to be used for providing a |
42 |
|
|
"checkpoint" distribution. Tagged configurations of tools built from this |
43 |
|
|
style of tree can be distributed, but because these trees do not have any |
44 |
|
|
polcies regarding testing of functionality, platform coverage or |
45 |
|
|
documentation these trees are not allowed to form the basis of |
46 |
|
|
"checkpoint" distrbutions or formal model releases. Other policies can |
47 |
|
|
be defined by individuals users of these trees but there are no further |
48 |
|
|
global policies. The GCMPACK repository development/ subdirectory is |
49 |
|
|
reserved for holding development trees. Development trees also serve as |
50 |
|
|
experimental areas for exploring new code management policies. |
51 |
|
|
|
52 |
|
|
o Checkpoint tree policies |
53 |
|
|
|
54 |
|
|
Checkpoint trees are intended to provide structured storage areas for |
55 |
|
|
holding code that is intended for open distribution and is to be readily |
56 |
|
|
downloaded. There are policies governing the operation of these trees |
57 |
|
|
which are designed to ensure that distributed codes are clearly |
58 |
|
|
identified and meet certain levels of quality. |
59 |
|
|
|
60 |
|
|
1. Check-out |
61 |
|
|
|
62 |
|
|
Just do it! Two mechanisms are available. cvsanon for read only access |
63 |
|
|
and regular cvs co .... for read/write access. |
64 |
|
|
|
65 |
|
|
2. Check-in. |
66 |
|
|
|
67 |
|
|
The code check in procedure for a "checkpoint" tree is as follows |
68 |
|
|
2.1 Check out the latest main branch revision. |
69 |
|
|
2.2 Merge your changes into that revision. |
70 |
|
|
2.3 Build and validate new code. |
71 |
|
|
2.4 Check that there have been no further changes to the |
72 |
|
|
repository. Repeat from 2.1 if repository has changed. |
73 |
|
|
2.5 Get clearance from other developers to check in your changes. |
74 |
|
|
2.6 Check in your changed main branch. |
75 |
|
|
2.8 Build and validate the new changes. |
76 |
|
|
2.9 Tag code as "checkpointNN". Add records to docs/tag-index. |
77 |
|
|
2.10 Build and validate test cases (see testing). |
78 |
|
|
2.11 Create and install checkpointNN.tar.gz |
79 |
|
|
|
80 |
|
|
3. Testing |
81 |
|
|
|
82 |
|
|
4. Checkpoint tagging |
83 |
|
|
|
84 |
|
|
5. Release tagging |
85 |
|
|
|
86 |
|
|
6. Branches |
87 |
|
|
|
88 |
|
|
Branches are to be used for bug-fixes and code patches to releases |
89 |
|
|
only. All other changes e.g. totally new features, bug-fixes to |
90 |
|
|
checkpoints are introduced by moving checkpoint levels forward. The |
91 |
|
|
only historical code maintenance that is employed is for fixes and |
92 |
|
|
patches to formal releases - not checkpoints. |
93 |
|
|
|
94 |
|
|
o These policies are causing me a big problem, what can I do? |
95 |
|
|
|
96 |
|
|
The policies are not enforced by any mechanism other than mutual |
97 |
|
|
agreement! If you think the policies are not appropriate then let us know |
98 |
|
|
and we can discuss changing them. However, if you simply ignore the |
99 |
|
|
policies regarding the checkpoint_release trees then your code may be |
100 |
|
|
removed and/or your access revoked. |
101 |
|
|
|
102 |
|
|
o What about bitkeeper |
103 |
|
|
|
104 |
|
|
We are looking at bitkeeper (www.bitkeeper.com). It looks cool, but |
105 |
|
|
policies are still important. Any experience, suggestions let us know. |
106 |
|
|
Watch this space! |
107 |
|
|
|
108 |
|
|
Questions, comments e-mail: gcmpack.code.czars@mitgcm.org |
109 |
|
|
|