Bugzilla – Full Text Bug Listing
| Summary: | Option To Automatically refresh compare/replace with another branch or version dialog | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Dani Megert <daniel_megert> | ||||||
| Component: | CVS | Assignee: | Jean-Michel Lemieux <jean-michel_lemieux> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | major | ||||||||
| Priority: | P5 | CC: | silvio_boehler | ||||||
| Version: | 3.1 | Keywords: | helpwanted | ||||||
| Target Milestone: | 3.1 M4 | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Dani Megert
Really 90%? In my case I've got a couple of branches with changes and don't want to auto-refresh because the branch lists are stable. I guess that if you are comparing/replacing against versions (e.g. integration builds) it may mean that you have to refresh once a week? Are you guys tagging that often? We removed the auto-refresh in 2.0 because people complained. >Really 90%? Yes really (I have 63 source shared source projects from different repositories with different development cycles - how many do you have?). > In my case I've got a couple of branches with changes and don't want >to auto-refresh because the branch lists are stable That's why it says "Option to..." ;-) >Are you guys tagging that often? At least once a week but the projects don't get tagged at the same day and not with the same tag pattern. Note: we also have shared source projects from other components in our workspaces. For me it's really a pain and in my workflow this looks like a blooper. Sometimes I have to replace a project with the newest tag but I don't know the tag. There's no indication that the dialog shows all tags and hence I am force to hit that button - no way around it. The current behavior is OK I think if you have few projects and if the projects have the same release cycle and tags and if you know the tags and the release/tagging cycle. So you would like to hit the server *everytime* we prompt for a tag? Of course this would be an option. I would keep the current behavior and add a preference that would enable auto-refreshing. Should be easy to do. Would you accept a patch along these lines? Sorry, I didn't want to change the priority. Yes, we would accept such a patch. However, I would suggest you self host on it for a week or two to get a feel for the performance impact of refreshing every time you open a dialog that displays tags. We (ZRH lab) switch daily to latest code and self-host on it ;-) Here's the first version of the patch which computes the tags in a low priority background job i.e. the dialog opens immediately and is responsive. This feature is off by default, however, given the fact that the implementation doesn't block the user in any way and we also want to reduce preferences I suggest you work with it for a while too ;-) and then decide whether the preference is really needed. Note that I copied the following constants 1:1 since I wasn't sure whether you use/like shared UI messages: TagRefreshButtonArea.0 -> TagSelectionDialog.2 TagRefreshButtonArea.1 -> TagSelectionDialog.3 TagRefreshButtonArea.2 -> TagSelectionDialog.4 TagRefreshButtonArea.3 -> TagSelectionDialog.5 TagRefreshButtonArea.4 -> TagSelectionDialog.6 TagRefreshButtonArea.5 -> TagSelectionDialog.7 The second part of the patch contains the help message for the preference page. Thanks, for considering this patch. Created attachment 16540 [details]
Patch for org.eclipse.team.cvs.ui
Created attachment 16541 [details]
Patch for org.eclipse.platform.doc.user
Patch released with a few changes. I've enabled background refresh when the refresh button is pressed in addition to if the preference is enabled. Sorry I have to reopen this bug: your modification to my patch now causes the following NPE when cancel gets pressed before the job finishes (see below). Rising severity since this is nasty for an S-build. !ENTRY org.eclipse.core.runtime 4 2 2004-12-15 09:34:25.126 !MESSAGE An internal error occurred during: "Refreshing tags". !STACK 0 java.lang.NullPointerException at org.eclipse.team.internal.ccvs.ui.tags.TagSelectionDialog.setBusy(TagSelectionDialog.java:301) at org.eclipse.team.internal.ccvs.ui.tags.TagSelectionDialog.access$2(TagSelectionDialog.java:299) at org.eclipse.team.internal.ccvs.ui.tags.TagSelectionDialog$4.run(TagSelectionDialog.java:279) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:66) No problem... I've found some other small things that I will fix for M4. *** Bug 81228 has been marked as a duplicate of this bug. *** Fixed in HEAD Hmm, if no tags are found in the background job, the user gets interrupted by a popup asking for further steps (deep search or manual configuration). That's intrusive, I think the job should just fail gracefully and let the user be in charge of taking additional mesures. I thought about that but decided that we want this dialog: if a user checked to have the tags updated and then sees no tags he might think that there are no tags. Your scenario seems academic or triggered by a test pass, isn't? ;-) If you decided during real work to either Replace or Compare with a version or a branch and now you have no tags it means you're now force to press the button in which then pops up that same dialog. Or do simply decide not to perform your work ;-) I vote for keeping as it is now. I second Dani's suggestion. There are cases where this could happen so it's not just academic, however rare it may be. I have opened a separate bug 81431 to track the issue. All further discussion of this will take place there. Verified that original issue of the PR is fixed. |