Summary: | Increase number of maintained histories | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Vlad Klicnik <klicnik> |
Component: | Update (deprecated - use Eclipse>Equinox>p2) | Assignee: | Konrad Kolosowski <konradk> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | major | ||
Priority: | P3 | CC: | jeem, John_Wiegand, manahan, patmc |
Version: | 2.0 | ||
Target Milestone: | 2.0 F3 | ||
Hardware: | PC | ||
OS: | Windows 2000 | ||
Whiteboard: | |||
Bug Depends on: | 19390 | ||
Bug Blocks: |
Description
Vlad Klicnik
2002-06-05 09:11:02 EDT
F3 candidate As an alternative, consider maintaining a full change log as a file that is appended on each install action (as part of writing new histories). This would be exposed via the About instead of the current history dump. Also, may consider dumping the current configuration with any status showing (warnings, errors) At least changing the default to a value beyond 5 (say 50) is an absolute (P1) rqmt per the product teams. If we do this - we should also reverse the order of display in the Update manager list... I'd rather have the active at the top and the order by FILO. Also - I just noticed, and only by picking up my tpad (1400x1050) and brining it close to my face, the running man icon overlay on the config. Maybe it should be offset a bit more, be a color, or be in the top right corner (or all of the above). View may be that this is more important than P3 (to get product team buy-in). The separate log idea is best. Then we can have a permanent history which is what we need for support. At that point how large the undo stack is irrelevant to us WS tools. We need the history. A separate log is a good suggestion for post 2.0 work. The near term fix is to increase the size of the history from 5. The size is controlled by an Install/Update preference, and is already accessible through the workbench UI. If the preferences is advertized as API, a product's plugin_customization.ini file could change the default value. A separate problem (19390) is preventing plugin_customization.ini from working. Don't like the idea of having to ask (as we would have to do in our RFWS validation) for all installs to adjust the default. If one plug-in could do this for all - fine. But as I understand it today, only the primary feature/plugin can adjust preferences via the customization.ini file approach. Looking like we must do one or more of the following (product team pressures): -Have the default raised to a reasonable number (50 or more) -Reverse the order of display in update manager -Limit the undo list in update manager to a shorter list than what is there in the history (would provide a logical log/undo separation) That said, customers on service calls will be asked to disable/enable recent activity - and we don't want to loose this if the list is short. Begs for a guide for the customer/service rep on how to approach making config changes: 1. save current config and adjust name to have a meaningful name (wish I could do this with F2). 2. Make config changes or undo recent updates. 3. Test behavior - return to 2 if required. 4. Commit config for runtime use 5. Save config and adjust name to have a meaningful name Initial changes released into HEAD together with fix for bug 19390. The order of histories and preservede states is reversed (most recent to least recent). The default is increased to 10. However, update.core is still not handling this correctly (trimming at 5) so keeping defect open. NOTE: F2 does have the ability to save the current configuration. The UI is not the most intuitive, so we should change it post 2.0 .... but the user can open Histories, and the most recent history == current configuration (has running man on the icon ... again, should fix visibility of the overlay post 2.1). Right click, Save, then go to the newly preserved configuration (in the Preserved folder) and change its name (right click, Properties). Like I said, the UI flow for this operation leaves lot to be desired, but the function is there. There is no limit on the number of preserved histories. Increased default number of histories to 50 as per conversation with Jim. Released interim workaround for 2.0 for handling of the preference setting between update core and update UI. Post 2.0, need to split out the use of histories for undo, and a separate service log. Opening a separate defect to track this |