Changes between Version 22 and Version 23 of HetProcedures/DevelInstall

Timestamp:

Nov 18, 2018 7:41:10 PM (6 years ago)

Author:

admin

Comment:

--

HetProcedures/DevelInstall

@@ -17 +17 @@
 '''Development'''
 
-  You can work in your own branch or trunk. For mid-sized or extensive modifications that may require intermediate commits, a branch is
-  recommended. Once you have tested as fully as possible the branch can be deployed in order to test on the hardware during the day or on the sky
-  at night.  If your changes don't work, redeploy the previous tag (see '''Deployment''' below). Once you are confident that your modification works,
-  then do a single merge with trunk.  In this manner, only one revision needs to be merged or back out in order to add or remove your modification.
-  When working in a branch, you should merge trunk  frequently to pick up the current working version
+  You can work in your own branch or trunk. For mid-sized or extensive modifications that may require intermediate commits, a branch is recommended. Once you have tested as fully as possible the branch can be deployed in order to test on the hardware during the day or on the sky at night.  If your changes don't work, redeploy the previous tag (see '''Deployment''' below). Once you are confident that your modification works, then do a single merge with trunk.  In this manner, only one revision needs to be merged or back out in order to add or remove your modification. When working in a branch, you should merge trunk  frequently to pick up the current working version
 
   If you are making only small changes that need only one or two commits, you can work in trunk... but don't break the build.
 
-  An alternate model would be for all changes to be committed to trunk as we are doing now and to have a permanent deployment branch that we merge working
-  commits into.  However, if there are extensive changes for one modifications we may have to merge many commits in order to get the full modification.
-  This seems prone to error to me.
+  An alternate model would be for all changes to be committed to trunk as we are doing now and to have a permanent deployment branch that we merge working commits into.  However, if there are extensive changes for one modifications we may have to merge many commits in order to get the full modification. This seems prone to error to me.
 
   Testing is important prior to releasing code on unsuspecting RA/TOs.  With a new deployment scheme it is easy to revert to a prior working edition.
+
+  If you need to test only your modification at night, then create a branch, make your changes, commit, and then install only the package(s) with the changes using the '-p' flag from `het_release`. Allow your version to run at night but be prepared to reinstall the current build (by running `make install [packages]` in the current build directory).
+
+  If testing during daytime only, then you can run the packages that have the changes. Replace the existing code before night operations are reinstall the existing version by doing `make install [packages]` in the current `build` directory. In this way we can keep track of what version are running at night during science operations.
 
 
 '''Deployment'''
 
-  * Current Deployment method
+  * Old Deployment method
     * roughly once per month create a new branch from trunk with the name branches/deployment/science/YYYYMMDD
     * build and install the branch
@@ -41 +39 @@
   * New Deployment method (still being debugged)
     * is done via the script `het_release`, for example I would use the following
-      * `het_release.sh -U fowler -a jrf@utexas.edu -b /opt/het/hetdex/src/tcs -r het-operations@het.as.utexas.edu -i /opt/het/hetdex -u hetdex:hetdex -P trunk`
-      * the command line flags for het_release are shown below. Note that -i is required for installation and -b is highly recommended. I use -U because my user name on hetdex-pr
-        is different that my user name on the machines at Het. The -P flag defaults to trunk but must be used if you want to install a branch or a tag.
+      * `het_release -U fowler -a jrf@utexas.edu -b /opt/het/hetdex/src/tcs -r het-operations@het.as.utexas.edu -i /opt/het/hetdex -u hetdex:hetdex -P trunk`
+      * the command line flags for het_release are shown below. Note that -i is required for installation and -b is highly recommended. I use -U because my user name on hetdex-pr is different that my user name on the machines at Het. The -P flag defaults to trunk but must be used if you want to install a branch or a tag.
 
     {{{