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

Diff of /mitgcm.org/cvspolicy.html

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

revision 1.1 by cnh, Sun Jul 2 14:44:33 2000 UTC revision 1.2 by cnh, Sun Jul 2 14:56:16 2000 UTC
# Line 1  Line 1 
1    <html>
2    <head>
3    </head>
4    <body>
5           GCMPACK CVS policies           GCMPACK CVS policies
6           ====================           ====================
7    
# Line 13  o Why have a policy? Line 17  o Why have a policy?
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
# Line 79  o Checkpoint tree policies Line 84  o Checkpoint tree policies
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
# Line 106  o What about bitkeeper Line 127  o What about bitkeeper
127    Watch this space!    Watch this space!
128    
129  Questions, comments e-mail: gcmpack.code.czars@mitgcm.org  Questions, comments e-mail: gcmpack.code.czars@mitgcm.org
130    </body>
131    </html>
Legend:
Removed from v.1.1  
changed lines
  Added in v.1.2
  ViewVC Help
Powered by ViewVC 1.1.22