Bug 257355 - [rulers] Team Annotate must be manually enabled for each file
Summary: [rulers] Team Annotate must be manually enabled for each file
Status: ASSIGNED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Text (show other bugs)
Version: 3.4.1   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Platform-Text-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-12-03 06:53 EST by Thorbjørn Ravn Andersen CLA
Modified: 2019-09-06 16:08 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thorbjørn Ravn Andersen CLA 2008-12-03 06:53:42 EST
Build ID: eclipse 3.4.1

Steps To Reproduce:
1.Open file backed by CVS
2.Coloured bar in left side showing CVS information on each line can be opened with Right click -> Team -> Show annotation
3.No preference can be found to enable this functionality on ALL files opened from CVS


More information:
For software legacy maintainers it is very beneficial to see version control information available to a given source file, and currently this must be manually enabled for each file opened in each new Eclipse session.

It would be very nice to have this functionality optionally enabled by default on all files backed by CVS.
Comment 1 Dani Megert CLA 2008-12-03 06:57:33 EST
The main reason for not being enabled by default is performance. However, we could do it in the background.
Comment 2 Markus Keller CLA 2008-12-03 11:31:40 EST
> Right click -> Team -> Show annotation

If you use this often, you might want to assign a keybinding to the command.
I use Alt+Shift+A.
Comment 3 Thorbjørn Ravn Andersen CLA 2008-12-03 11:40:37 EST
(In reply to comment #1)
> The main reason for not being enabled by default is performance. However, we
> could do it in the background.

I agree that the default configuration should concentrate on performance for the many.   I would personally not mind taking the performance hit, if I'd explicitly enabled this myself in a preference panel.  Our CVS-server is in the next room.

Another possible place could be on each CVS repository as some are nearby and others very distant.

Comment 4 Dani Megert CLA 2008-12-03 11:42:36 EST
Note that it's not only a concern of your workspace but also a question how hard the CVS server will be hit if many people enable the feature.
Comment 5 Thorbjørn Ravn Andersen CLA 2008-12-03 13:24:10 EST
(In reply to comment #4)
> Note that it's not only a concern of your workspace but also a question how
> hard the CVS server will be hit if many people enable the feature.

I am aware of that.  Hence the default setting of off.

In our group it would be perfectly fine to have this on for all developers.
Comment 6 Tom Hofmann CLA 2008-12-04 04:03:33 EST
I guess Team team could already do this. They would simply have to listen for editors being opened, then fetch annotate information and display in on the editor using ITextEditorExtension4.

(In reply to comment #1)
> The main reason for not being enabled by default is performance. However, we
> could do it in the background.

The annotate information is already fetched in the background, so there wouldn't be any additional concurrency issues.

(In reply to comment #3)
> Another possible place could be on each CVS repository as some are nearby and
> others very distant.

Enablement per project or per repository would be required - otherwise, you could really put some load on those sourceforge servers...

Comment 7 Dani Megert CLA 2008-12-07 11:39:50 EST
>The annotate information is already fetched in the background, so there
>wouldn't be any additional concurrency issues.
Right. I was also thinking of the server. Though not processing the requests in the bg it might want to give it lower prio.

Comment 8 Eclipse Webmaster CLA 2019-09-06 16:08:07 EDT
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.