<p><b>duda</b> 2010-03-16 11:27:49 -0600 (Tue, 16 Mar 2010)</p><p>Add initial version of repository guidelines and procedures document.<br>
<br>
A repository_guidelines.txt<br>
</p><hr noshade><pre><font color="gray">Added: trunk/documents/repository_guidelines.txt
===================================================================
--- trunk/documents/repository_guidelines.txt (rev 0)
+++ trunk/documents/repository_guidelines.txt 2010-03-16 17:27:49 UTC (rev 138)
@@ -0,0 +1,64 @@
+1) Advanced notice of changes to the repository trunk should be given to
+other MPAS developers through mpas-developers@ucar.edu at least 24 hours
+before committing. The notice should indicate the reason for the change, the
+expected impact of the change (i.e., is the change expected to affect model
+results), and a summary of the changes to the source code. When feasible --
+for example, when the changes don't affect a large number of files -- the
+modified source files should be attached to the e-mail to allow other
+developers to see and test the actual code that is to be committed; ideally,
+developers will have the opportunity to spot any potential problems in the
+code or offer any suggestions on how to improve the code (e.g., how make it
+more robust) before it is committed. Before committing the changes to the
+trunk, one representative from each partner (currently LANL and NCAR) must
+"sign off" on the changes.
+
+2) Code to be committed to the trunk should meet as-yet unspecified coding
+standards. For now, it should be sufficient for the code to use consistent
+indentation, descriptive variable names, and be adequately commented.
+Comments such as "MGD changed 2010-03-11" should be avoided, since a search
+through the revision history of a file should suffice to let others know who
+made which changes.
+
+3) No matter how small a change, before actually committing the code change
+to the trunk, the working copy of the code should be updated with respect to
+the top of the repository, and a simple regression test performed on the
+updated code. Until a standard regression test is developed, testing before
+a commit should, at a minimum, include compilation of the updated code and a
+run of a short simulation; if it is known that the change will affect
+specific functionality, that functionality should undergo additional
+testing. It is important that the code be tested once it has been updated
+with respect to the top of the repository, since recent changes to the
+repository trunk could conflict with the changes in a developer's working
+copy.
+
+4) Code changes that would leave the trunk in an unusable state should never
+be committed to the trunk.
+
+5) Whenever possible, sets of unrelated changes should be added to the
+repository as separate commits; for example, if a developer had code updates
+for a physics routine as well as an infrastructure routine, these two
+updates should use separate commits. Essentially, each commit should be
+specific to one purpose.
+
+6) Before committing from a working copy, a developer should verify that the
+only files that will be committed are those intended. This can be done by
+typing 'svn status' in the working copy and verifying that the only files in
+the list are those that should be committed. The purpose of this guideline
+is to prevent changed from unintentionally being committed; for example, a
+developer may be working on changes in a file foo.F and might have also made
+changes to other files for the purpose of testing, in which case, typing
+simply 'svn commit' in the working copy top-level directory would also
+commit the changes from testing.
+
+7) The commit message should include a list of the files that were changed
+during the commit. This makes it easier for another developer to look
+through the svn log at a later date and identify exactly which files were
+affected by each commit.
+
+8) Development in repository branches is not subject to the procedures for
+committing to the trunk. Branches allow a developer to work on a more
+extensive feature or change without being slowed down during development by
+the process applied to the trunk.
+
+
+Initial version: 15 March 2010
</font>
</pre>