Community
Participate
Working Groups
in version 3.0, comparing with the local history was an easy task. The comparison dialog was fast, and every single click in the history pane showed the corresponding changes in the comparison pane. Cleaning up the UI was as easy as closing the dialog. In 3.3, someone apparently decided that this was too easy and not to their taste. Now a history view appears, and I have to double click on each line to have the comparison editor appear. The UI is rather slow as the full perspective gets updated. Quickly switching between versions is no more possible. To clean up the UI I have to close the editor AND the history view. One more dehancement IMO. PLEASE give us back at least the option to see the dialog
>>someone apparently decided that this was too easy and not to their taste Sarcasm isn't helpful, by the way.
Try turning on the following options: Team > CVS > Synchronize/Compare > Show revision comparisons in dialog General > Open Mode > Single Click Then select a file and do Compare With > History.... The dialog will pop up. It can be limited to show only local revisions. With the single-click option on you should also get a similar experience while switching between versions. Moreover, please notice few new options there like: copy from left to right and vice-versa, structure comparison and so on.
that does not help. Firstly, it seems odd that one would have to change CVS-related preferences to change the behavior of the local history compare. Secondly, after changing the setting you mention, and selecting "Compare with->Local History", I still get the view, and no dialog. Thirdly, I am using subversion.
I suggested to select "Compare With > History...". Please, give it a try before answering again.
sorry, dont know what you're talking about. As I said I am using subversion and dont have a CVS project in my workspace. Hence there is no option "Compare with->History". In any case, I want to compare against local history. Do you have anything to contribute to that?
Here is the rational behind the change you have encountered. We found that, when people are comparing with local history, in some cases they want to use the action as you have indicated but in others, they would actually like to compare previous versions in the local history with Each other. There was also requests to make the comparison non-modal. Moving the comparison to the history view solved these issue. However, as you say, this can make the workflow you described less optimized (i.e. you can still do it but it takes a few more clicks). It turns out that the Replace with Local History does open in a dialog since that made more sense for the replace workflow.
but why was the previous functionality removed, which as you admit was more efficient in certain contexts? Why not at least leave a preference switch under "General->Compare/Patch"?
Preferences do not have a zero cost for either the user or the developer/maintainer of the code. At the time the change was made, feedback from users was obtained and the consensus was that a preference was not required (i.e. everyone involved felt the new workflow was superior). If you feel differently, you are welcome to provide a patch that adds a preference.
the cost for the developer is negligible IMO, in particular when it is done right away. To provide the patch I would have to (or like to) know whether the old dialog is still in the code base.. Regarding the cost for the user one would have to differentiate between the users whose workflow gets broken and those who appreciate the innovation. Lets assume they level eachother. It seems I really need to join that group of users whose feedback is obtained before changes like this one are made. This is not the first one that makes me consider staying with 3.2.
The old dialog is still in the code base. It is found in the org.eclipse.compare plug-in (CompareWithEditionAction). However, this introduces some complications since the action is internal to compare and the new page based local history compare is provided by Team. Another option would be to duplicate the logic used in the ReplaceLocalHistory action in the org.eclipse.team.ui plug-in in the CompareLocalHistory action. In either case, the changes would need to be made in the CompareLocalHistory action and a preference would need to be added to toggle the behavior. In regards to using the latest Eclipse builds, it has it pluses and minuses. On the plus side, you get all the new features sooner than most and can provide feedback. On the down side, although rare, there are inevitably some problems and it is not always feasible depending on how your Eclipse is configured (i.e. what other plug-ins do you use and are they compatible with the latest Eclipse). I think the majority of non-committers who are early adopters adopt each milestone build as they are fairly stable.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
