Currently, the migration code I checked in with a recent chart update deletes and remigrates all the chart data. This isn't good, really - it's been too long, and the corruption window was quite small anyway. Myk and I have decided it's best to document the issue and let people nuke their own data if they want :-) This bug covers backing out the auto-nuking and updating the docs.
Created attachment 163969 [details] [diff] [review] Patch v.1 This patch should hopefully do the trick. As for "updating the docs", I think this is an appropriate subject for a section in the release notes. "If you updated to a development release (2.17.5 or 2.17.6) or CVS snapshot between 2003-06-25 and 2004-02-12, and then edited some charts (either your own or auto-created) before updating to a release post-2004-02-12 (e.g. 2.17.7 or later) then the charts you edited may be corrupted, and be getting invalid data. It is suggested that you create new charts for those queries and move the old ones somewhere out of the way (currently there's no deletion mechanism)." I'm sure that can be phrased better. Gerv
Comment on attachment 163969 [details] [diff] [review] Patch v.1 >- print "Deleting possibly-corrupt new-chart data " . >- "(it will be re-migrated) ...\n" unless $silent; Geez, how did this ever pass review? ;) That should have never been masked when in silent mode, that's one of those things that the sysadmin really *would* have wanted to see in his cron mail :) Otherwise, this looks good to me, let's get it in before the upgrade this weekend :)
Fixed on trunk: Checking in checksetup.pl; /cvsroot/mozilla/webtools/bugzilla/checksetup.pl,v <-- checksetup.pl new revision: 1.315; previous revision: 1.314 done Fixed on branch: Checking in checksetup.pl; /cvsroot/mozilla/webtools/bugzilla/checksetup.pl,v <-- checksetup.pl new revision: 1.289.2.13; previous revision: 1.289.2.12 done Gerv