| 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 |
|
Parent Directory
| 
Revision Log
| 
Revision Graph