/[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.1 - (show annotations) (download) (as text)
Sun Jul 2 14:44:33 2000 UTC (21 years, 10 months ago) by cnh
Branch: MAIN
File MIME type: text/html
Added initial draft project policy on CVS

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

  ViewVC Help
Powered by ViewVC 1.1.22