| 1 |
GCMPACK CVS policies |
<html> |
| 2 |
==================== |
<head> |
| 3 |
|
</head> |
| 4 |
|
<body> |
| 5 |
|
MITGCM CVS policies |
| 6 |
|
=================== |
| 7 |
|
|
| 8 |
o Introduction |
o Introduction |
| 9 |
|
|
| 10 |
This note describes policies that apply to the GCMPACK CVS repository |
This note describes policies that apply to the MITGCM CVS repository |
| 11 |
|
|
| 12 |
o Why have a policy? |
o Why have a policy? |
| 13 |
|
|
| 17 |
tracked. If CVS is used without any other policy the result can be a |
tracked. If CVS is used without any other policy the result can be a |
| 18 |
collection of files each of which has complex, multiply branched set of |
collection of files each of which has complex, multiply branched set of |
| 19 |
interelated versions. This sort of CVS repository can be come like a |
interelated versions. This sort of CVS repository can be come like a |
| 20 |
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 |
library where books are simply stored in a huge heap. Although nothing is |
| 21 |
|
actually lost, the task of finding a coherent collection of material soon |
| 22 |
becomes impossible. |
becomes impossible. |
| 23 |
|
|
| 24 |
The policies we employ address two areas |
The policies we employ address two areas |
| 25 |
1. Maintaining an orderly and easily identifiable, coherent set of |
1. Maintaining an orderly and easily identifiable, coherent set of |
| 26 |
evolving "products". |
evolving "products". |
| 27 |
2. Allowing concurrent, on-going development of products. |
2. Allowing concurrent, on-going development of product components. |
| 28 |
|
|
| 29 |
o Development trees and checkpoint trees |
o Development trees and checkpoint trees |
| 30 |
|
|
| 31 |
A directory within the GCMPACK repository resides under either the |
A directory within the MITGCM repository resides under either the |
| 32 |
development branch or the checkpoint branch. Files within each branch |
development branch or the checkpoint branch. Files within each branch |
| 33 |
follow different policies. |
follow different policies. |
| 34 |
|
|
| 41 |
a particular person, a certain project or a particular special piece of |
a particular person, a certain project or a particular special piece of |
| 42 |
work. These trees are intended to be useful areas for storing current |
work. These trees are intended to be useful areas for storing current |
| 43 |
work and for archiving partially finished work so that it doesn't get |
work and for archiving partially finished work so that it doesn't get |
| 44 |
mislaid and s that some record of the development history can be easily |
mislaid and so that some record of the development history can be easily |
| 45 |
maintained. The only policy that applies to development trees is that |
maintained. The only policy that applies to development trees is that |
| 46 |
this style of tree is not intended to be used for providing a |
this style of tree is not intended to be used for providing a |
| 47 |
"checkpoint" distribution. Tagged configurations of tools built from this |
"checkpoint" distribution. Tagged configurations of tools built from this |
| 48 |
style of tree can be distributed, but because these trees do not have any |
style of tree can be distributed, but because these trees do not have any |
| 49 |
polcies regarding testing of functionality, platform coverage or |
polcies regarding testing of functionality, platform coverage or |
| 50 |
documentation these trees are not allowed to form the basis of |
documentation these trees are not allowed to form the basis of |
| 51 |
"checkpoint" distrbutions or formal model releases. Other policies can |
"checkpoint" distrbutions or formal "releases". Other policies can |
| 52 |
be defined by individuals users of these trees but there are no further |
be defined by individuals users of these trees but there are no further |
| 53 |
global policies. The GCMPACK repository development/ subdirectory is |
global policies. The MITGCM repository development/ subdirectory is |
| 54 |
reserved for holding development trees. Development trees also serve as |
reserved for holding development trees. Development trees also serve as |
| 55 |
experimental areas for exploring new code management policies. |
experimental areas for exploring new code management policies. |
| 56 |
|
|
| 84 |
|
|
| 85 |
3. Testing |
3. Testing |
| 86 |
|
|
| 87 |
|
Things in a checkpoint tree require a test case that |
| 88 |
|
can be used to validate the component. |
| 89 |
|
|
| 90 |
4. Checkpoint tagging |
4. Checkpoint tagging |
| 91 |
|
|
| 92 |
|
No code should be left in limbo. Checking in code and then |
| 93 |
|
leaving it in the repository untagged is bad. When you check |
| 94 |
|
in code you are creating a new checkpoint. That means you don't |
| 95 |
|
check in some code which you "know" works 100% and then go away |
| 96 |
|
for two weeks. When you start checking in code you make sure |
| 97 |
|
you have time to do the process end-to-end as described in section |
| 98 |
|
2. |
| 99 |
|
|
| 100 |
5. Release tagging |
5. Release tagging |
| 101 |
|
|
| 102 |
|
Releases are only based on checkpoint tree code. Maintenance fixes |
| 103 |
|
to releases are also maintained within the checkpoint tree. Files |
| 104 |
|
within a release must have accompanying documentation. The form of this |
| 105 |
|
documentation depends on the file type. |
| 106 |
|
|
| 107 |
6. Branches |
6. Branches |
| 108 |
|
|
| 109 |
Branches are to be used for bug-fixes and code patches to releases |
Branches are to be used for bug-fixes and code patches to releases |
| 126 |
policies are still important. Any experience, suggestions let us know. |
policies are still important. Any experience, suggestions let us know. |
| 127 |
Watch this space! |
Watch this space! |
| 128 |
|
|
| 129 |
Questions, comments e-mail: gcmpack.code.czars@mitgcm.org |
Questions, comments e-mail: code.czars@mitgcm.org |
| 130 |
|
</body> |
| 131 |
|
</html> |
Parent Directory
| 
Revision Log
| 
Revision Graph
| 
Patch