X-Git-Url: https://scripts.mit.edu/gitweb/wizard.git/blobdiff_plain/559c9e20d0dd1c0c8b944a94d9fea82791d49e46..2b5c97328b4b24ff129966b8ee33cac07c560cc1:/doc/upgrade.rst

diff --git a/doc/upgrade.rst b/doc/upgrade.rst
index 0cb405b..5768c96 100644
--- a/doc/upgrade.rst
+++ b/doc/upgrade.rst
@@ -25,7 +25,7 @@ First you prepare the pristine copy::
 
     git checkout pristine
     wizard prepare-pristine $APP-$VERSION
-    git commit -asm "$APPLICATION $VERSION"
+    git commit -sm "$APPLICATION $VERSION"
     git tag $APP-$VERSION
 
 Next, you merge those changes to the scriptsified ``master`` copy::
@@ -33,35 +33,52 @@ Next, you merge those changes to the scriptsified ``master`` copy::
     git checkout master
     git merge pristine --no-commit
     # resolve conflicts
-    git commit -asm "$APPLICATION $VERSION-scripts"
+    git commit -sm "$APPLICATION $VERSION-scripts"
 
 .. note::
 
     If you are creating a fix for a previous scripts version, you should
     bump the version to ``$VERSION-scripts2``.
 
-Then, on a scripts server with Wizard pointed at the latest version, run::
+If the files associated with installation (for example, the install
+script) have changed, we need to double check that the configuration
+files are in order.  On a scripts server with Wizard pointed at the
+latest version, run::
 
     cd tests
-    env WIZARD_NO_COMMIT=1 ./test-install-$APP.sh
-    cd testdir_install_$APP_head
+    env WIZARD_NO_COMMIT=1 ./$APP-install-test.sh
+    cd testdir_$APP_install_head
     wizard prepare-config
 
-With any luck, there will be no differences; if there are
-manually restore any custom changes we may have made to the configuration
-file, make sure that no upstream changes broke our regular expressions
-for matching.  Then amend your commit and push back::
+With any luck, there will be no differences.  However, if there are
+changes, manually restore any custom changes we may have made to the
+configuration file (a ``git checkout -p`` should allow you to
+selectively back out the relevant bits).  Furthermore, make sure that no
+upstream changes broke our regular expressions for matching.  The merge
+your changes back (preferably via your local machine, since you probably
+don't have appropriate author credentials setup to be accessible
+on Scripts)::
 
     git commit --amend -a
     git tag $APP-$VERSION-scripts
     git push --force
     git push --force --tags
 
-On any other copies that have the older commit, run the following commands
-while on the ``master`` branch to grab the new version::
+.. note::
+
+    If you have a split AFS and local Wizard setup, you may prefer to
+    instead create a dummy commit and do the merging in your local copy.
+    The flow looks like::
 
-    git fetch --tags $REMOTE
-    git reset --hard $REMOTE/master
+        # from the scripts copy
+        git commit -asm "Dummy"
+        git push
+        # from your copy
+        git pull
+        git reset HEAD~
+        git commit --amend -a
+        git tag $APP-$VERSION-scripts
+        git push -f
 
 Be sure to verify that your commit is the correct one; you can check with
 ``git show``, which should show the changes you made when amending the
@@ -112,6 +129,12 @@ Finally, :meth:`~wizard.app.Application.upgrade` actually performs an upgrade,
 and will most frequently call a shell script or fetches a web page that will
 perform a schema upgrade.
 
+.. note::
+
+    When migrating an old-style autoinstall, it is neither expected nor
+    required for upgrade scripts for the intervening versions to be
+    created.
+
 Troubleshooting
 ---------------
 
@@ -175,9 +198,10 @@ to these tags::
     git checkout -b tpristine
     git reset --hard 1.0
 
-Find the committer time associated with the ``tmaster`` commit using ``git show tmaster``
-and note it somewhere (we will refer to it in the environment variable
-``$DATE``.)
+Find the committer date associated with the ``tmaster`` commit using ``git show tmaster``
+and note it somewhere::
+
+    DATE=`git show tmaster --pretty="format:%cd" | head -n1`
 
 Next, begin performing ordinary procedure for preparing the
 pristine copy.  There are two caveats:  you will need to use ``--force``
@@ -220,10 +244,11 @@ Note that ``$VERSION`` is specified explicitly.  If there are changes,
 manually restore any custom changes we may have made, then amend your commit and
 push back::
 
-    git commit --amend -a
+    # you probably lost your environment variable
+    DATE=`git show HEAD --pretty="format:%ad" | head -n1`
+    env GIT_AUTHOR_DATE="$DATE" GIT_COMMITTER_DATE="$DATE" git commit --amend -a
     git tag -d $APP-$VERSION-scripts
     git tag $APP-$VERSION-scripts
-    git push --force
     git push --force --tags
 
 And on your now invalid version, grab the new version::