I would like to learn appropriate lessons from a recent incident.
Prior to reporting a system bug, I wanted to ensure my system was up-to-date.
1) svn update in webwork/pg got updates to lib/PGcore.pm and 2 files in macros
2) svn update in webwork/webwork2 got message
Failed to add file 'htdocs/css/math2.css': an unversioned file of the same name already exists
FWIW: I've gotten that message previously, but interpreted it to mean that my local revision of the linked file was not yet within Subversion's scope.
3) That math2.css was a symbolic link and I renamed that link (not the linked file). A subsequent "svn update" in webwork/webwork2 let me acknowledge that I wanted to keep my version of site_info.txt and then it proceeded to update and add a variety of items (to revision 7139). It restored htdocs/css/math2.css as a symbolic link to a freshly downloaded file (in ../../conf/templates/math2).
4) the trivial example I planned to use in reporting the system bug now gave an error which mentioned "maketext". This seemed to be a crisis event which would affect all students using my system.
5) webwork2/bin/check_modules.pl had been updated and "check_modules.pl apache2" now reported
** Locale::Maketext::Lexicon not found in @INC
so I su'd to use "perl -MCPAN -e shell" in order to "install Locale::Maketext::Lexicon"
6) after "apache2ctl graceful", my bug-example does not produce an error message (AND it does not exhibit the bug I planned to report).
From timestamps of several files, I think this disruption lasted less than 15 minutes. If I'd not made some lucky guesses, the result could have been more serious.
In hindsight, I should have recorded the revision number for my then-current version of WeBWorK (but svn status did not give the relevant info) --- that might have allowed me to revert quickly to a working (but only mildly sub-optimal) system. I'm still learning Subversion and will welcome details about how I could have been more cautious. (E.g., what would have been a better way to handle the error message cited in item 2?)
I see no adverse effects to frequent uses of "svn update" in the NPL (with NPL-update invoked after additions and, perhaps, after updates which might have changed tagging), but I think extreme caution is required elsewhere. What source of system-update info am I overlooking?
Hi Dick,
I think that's a fairly standard update under the current system. Notice that pg and NPL update fairly easily, and webwork2 is usually a bit more difficult.
That's what I expect when I do updates.
To get the current revision number use
svn info
and look for the revision number #revision.
svn update -r #revision
will restore that version
This gives you a good backup. You can also make a local copy of global.conf in global.save for extra backup.
svn status -u will tell you what files have changed locally and which ones have changed upstream in the repository.
The conflict you saw was most likely because you had locally made that symbolic link and the same symbolic link had been made in the repository. What you did was just what I do in those situations. (While fixing this there was no effect on the behavior of the server. The two links were identical but svn didn't know that.)
If you are cautious and remember you can run check_modules.pl before you first restart the server to check the new update. Usually nothing changes after an svn update until you reboot the server, so you can catch and install missing modules while the system is still operating on the old cached code.
One thing you don't mention is checking to see if there are changes in global.conf.dist which need to be transferred over to global.conf. Frequently this is a prime source of warning messages (and sometimes fatal errors) when you switch over. The new configurations are required before the new features can work. This is one case where changes take place immediately, but usually if you change global.conf before the restart there is no problem because there are only additions to global.conf and they are ignored by the current system.
Expecting 15 minutes of work to get a new version of webwork2 up and running is about right if you are already pretty up-to-date. Notice that the system was probably down for a smaller fraction of that time during the period when you were installing the Lexicon module.
-- Mike