Community
Participate
Working Groups
If a project is under CVS, the quickdiff should default to showing differences aginst CVS. Øyvind
Quickdiff is platform/text
The quick diff provider default is per workspace. If we change it automatically to the current team provider then we should show this somewhere to the user, e.g. by offer this setting per project. Also, we have to update this setting when the user starts (un-)sharing a project. Adapated the summary to any team provider - not just CVS.
Note that you can set the default quick diff referenc in the preferences - not sure whether changing the default-default is a good thing, as the disk reference is always available, but not the team provider. See the preferences: Workbench->Editors->TextEditor->QuickDiff and Java->Work in Progress
>Note that you can set the default quick diff referenc in the preferences - >not sure whether changing the default-default is a good thing, as the >disk reference is always available, but not the team provider. My main concern is that there shouldn't have to be any options. A good option is no option. I just can't imagine a circumstance where quickdiff in in a project under CVS should diff against whats on the disk as opposed to the the respository. Øyvind
> My main concern is that there shouldn't have to be any options. A good option is > no option. Guess you're right. The problem will be to figure out whether there is a team provider available at all. If we introduce a per project setting, the team process could set / unset the default provider when it gets (un-)installed. Not sure when this will happen - this is a contribution opportunity...
Changed caption, as the crux of the problem is that there shouldn't be any option. Øyvind
I think this is a good request. I think the whole purpose of this feature (QuickDiff) is to compare against team state. What kind of short term memory would you have to have to not remember what you typed in the last 20 seconds, which is probably the average time an editor stays dirty. Most users never discover the CVS setting in preferences. Also, what if the user has both CVS and Clearcase projects loaded in their workspace?
>I think this is a good request. I think the whole purpose of this feature >(QuickDiff) is to compare against team state. What kind of short term memory >would you have to have to not remember what you typed in the last 20 seconds, >which is probably the average time an editor stays dirty. Well put. :-) Remove "quick diff against latest saved version". It makes no sense. Øyvind
How exactly will Quick Diff react when using other Team providers ? Actually I'm interested in ClearCase requirements and enhancements. I was reading bug 47807 and I think these 2 are related if we consider that we may want to specify version or even another file (quite uncommon I admit). Specify another version is particularly common when mantaining existent code or porting code from diferent software baselines.
Tom, please comment.
Any team provider can contribute to the quickDiffReferenceProvider extension point - if a specific team provider does not do so, you should file a bug report against it. This PR requests that quick diff should, for any given resource, automatically select the quickdiff reference of the resource' team provider. The problem here is that quick diff has no explicit notion of a 'team provider'. Implementing the request would require a query to each provider, asking whether it is available for the current editor/document/resource. This could probably be implemented via the existing setActiveEditor / isEnabled methods, but it would look like a hack as these methods serve a different purpose as well.
Is there such a thing as a useful quickdiff provider which is not team based? Maybe new api could be added to determine the most interesting provider for a resource. The compare-with-saved-contents provider would return the minimum interest "score".
I personally use the team provider only, but I do know of people using the last-saved provider... But I would not be against getting rid of it either, and certainly not against removing the preference. It's all a question of time, API changes and many other things that could be done better with the IQuickdiffReferenceProvider API...
Not all projects are shared and not every team provider might offer a reference provider. For those it makes sense to have the last-saved provider.
(In reply to comment #4) > My main concern is that there shouldn't have to be any options. A good option is > no option. > > I just can't imagine a circumstance where quickdiff in in a project under CVS > should diff against whats on the disk as opposed to the the respository. I use this feature quite a bit. Here's a simple example: a file not yet in CVS. A solid quickdiff bar telling me I've added 184 lines means little to me. Another case would be when significant changes have been made to a file that is in CVS. Sometimes I need to see what I've just been working on recently. An extension of that could be that I did some work on one day, and continued it on another.
> in CVS. Sometimes I need to see what I've just been working on recently. An > extension of that could be that I did some work on one day, and continued it on > another. So, you only save your changes once a day?
(In reply to comment #0) > If a project is under CVS, the quickdiff should default to showing differences > aginst CVS. I strongly vote against this change. Quickdiff is immensely valuable to find out what editing changes have been made in a buffer. This is still useful when a file is under CVS management. It is a feature that is unfortunately rarely found in other editors and hence one that gives additional value to Eclipse.
Since there are votes for keeping the "Version on Disk" provider, we won't remove the preference. The quest is then to default to the available team provider if there is one.
The default diff should still change to CVS, which is what comment 0 says depsite the summary. I find it hard to believe that the average user doesn't remember what changes they made since the last time they pressed CTRL+S.
I think it is reasonable to allow a repository provider to provide the default quick diff for files shared with that repository. However, if this were supported, I would also argue that the Show Quick Diff option in the editor should be off by default. It is just not a good idea to have options that result in round trips to the server without the user explicitly idicating that it is OK.
Why not make a quick diff against the base version, and always keep the base version in the local history? No round trip required. And it functions offline.
That makes good sense and we could definitly do this for CVS. We can't assume that other repository providers would do this though so there would have to be a way to indicate whether the repository provider wanted to be the default quick diff.
Would you need support from core to keep a certain local version of a file around? Or would you just create your own copy of the base? I think diffing against the base is more interesting than comparing against other developer's released changes. If I haven't modified a file, I want to see nothing in the quickdiff, rather than incoming changes.
CVS would need to cache the base in such a way that it was always available.
*** Bug 155531 has been marked as a duplicate of this bug. ***
holy cow this is an old bug that is still open after so much discussion. maybe i can revive it and bring it into the backlog? here is my thing why: i'm currently doing some PDE eclipse dev. and hence have to work with 3 team providers. a) CVS for the eclipse stuff b) SVN for some other code i build on c) mercurial for my own code having to constantly change between providers as this is a workspace global setting is very cumbersome and not very helpful! i propose the following behavior: - be able to select a diff. quickdiff provider (QDP) than the default WS QPD per project or even resource! - have a generic quickdiff provider that can be named and config'ed per team provider and that controls by preference order which QTP is used if there be >1 team providers present per project. e.g. in my case: i would select the generic QDP for the WS - select the team provider's respective QDP and be done each team i open a resource in any of the projects the correct QDP would be used.
Some of my colleagues have still recently been confused by this. It seems unnatural that the default reference source is "Version on Disk" for Git projects for instance. And unfortunately they started looking in the Team/Git preferences rather than Text Editors/Quick Diff to try to fix the setting, further increasing frustration.
(In reply to Pierre-Yves B. from comment #27) > Some of my colleagues have still recently been confused by this. It seems > unnatural that the default reference source is "Version on Disk" for Git > projects for instance. And unfortunately they started looking in the > Team/Git preferences rather than Text Editors/Quick Diff to try to fix the > setting, further increasing frustration. Can you provide a Gerrit to change the default? If it is just a preference, you should be able to find its key fast with the preference spy. See https://www.vogella.com/tutorials/EclipseRCP/article.html#tutorial_installation_e4spies
(In reply to Lars Vogel from comment #28) > Can you provide a Gerrit to change the default? If it is just a preference, > you should be able to find its key fast with the preference spy. See > https://www.vogella.com/tutorials/EclipseRCP/article. > html#tutorial_installation_e4spies Unfortunately, this is not as simple as changing the default. As pointed out by other messages, there is an open question about whether this should become a per-project setting. For example, my main workspace at work contains a mixture of Git, SVN and non version-controlled projects, there is no one solution fits all at the workspace level (though selecting either of the team providers would be a better solution in my case). Some users were even questioning whether this should even be an option at all. If the IDE adequately chooses the right provider on a per-project basis, what would be a valid use-case for changing it nowadays (CVS round trips was one of the reasons pointed out 15 years ago)? Some thoughts about the difficulties of the implementation were given in https://bugs.eclipse.org/bugs/show_bug.cgi?id=46090#c11, but are these still relevant nowadays?
