Community
Participate
Working Groups
I think we should customize the Eclipse SDK so that the History View is automatically synchronized with the current selection. I have several times seen people (including myself) wondering over the empty History View. Maybe we can change that preference setting in our Eclipse SDK build and ask to do EPP the same? Opinions?
We just discussed that on EclipseCon in our Git/Gerrit and the overall feedback was that this should be the default setting.
Dani, sorry can't find team in https://projects.eclipse.org/projects/eclipse.platform but I think you are responsible for this project. Would you be in favor of setting this as default?
Dani, are you the component lead for team?
This could have high performance impact based on the team provider. We can either close as WONTFIX or have a closer look during 4.5.
Marking as WONTFIX for Luna, if required I open a new bug for Mars
(In reply to Lars Vogel from comment #5) > Marking as WONTFIX for Luna, if required I open a new bug for Mars No need to create a new bug, you can reopen this one if needed.
In Platform UI Andrey fixed the update of the History view if it is not visible. See https://git.eclipse.org/r/#/c/67089/ With that, I think we should make the "Link with Editor and Selection" the default. Background: I delivering a EGit training this week and the "why is my History view" empty is the most frequently question. I think changing the default here, will help new developers to use the History with less issues, while experience developers will know where to change this.
Matthias/ Andrey, any input from the EGit team on this?
From a usability perspective this would make a lot of sense. It could affect performance but nowadays EGit is pretty fast also on large repositories. I think I always switch this linking on hence +1 from me
(In reply to Lars Vogel from comment #8) > Matthias/ Andrey, any input from the EGit team on this? I have it always on and even with our monster repo I see no performance issues (on Eclipse 3.8). We should enable it if the platform version is >= 4.6, since earlier 4.x would cause unexpected refreshes.
ok, so looks like we have agreement to switch linking on by default if the team provider is EGit, don't know for other team providers (see Dani's comment 4)
(In reply to Matthias Sohn from comment #11) > ok, so looks like we have agreement to switch linking on by default if the > team provider is EGit, don't know for other team providers (see Dani's > comment 4) There's only one setting for the view (doesn't depend on the provider). Personally I also have it enabled, but I heard from people not having an SSD, that the History view updating can badly slow down the whole machine while (E)Git provides the input for the history. Is anyone on this bug not using an SSD and can comment on that?
(In reply to Dani Megert from comment #12) > (In reply to Matthias Sohn from comment #11) > > ok, so looks like we have agreement to switch linking on by default if the > > team provider is EGit, don't know for other team providers (see Dani's > > comment 4) > > There's only one setting for the view (doesn't depend on the provider). > > Personally I also have it enabled, but I heard from people not having an > SSD, that the History view updating can badly slow down the whole machine > while (E)Git provides the input for the history. Is anyone on this bug not > using an SSD and can comment on that? If the find toolbar isn't shown (which is the default) EGit's history view loads the history incrementally in chunks of 256 commits. In addition there is a limit to not show more than 10k commits (preference "Team > Git > History > Max number of commits to show"). For large repositories the WindowCache limit (preference "Team > Git > Window Cache > Window Cache limit") is probably too small, increasing that should avoid repeated loading of the same objects from disk.
if we have someone who can reproduce this slowness they can use tracing to trace the history view: - type "trace" in quick access and select "Configure Git Debug Trace" - enable trace for plug-in org.eclipse.egit.ui - enable trace "/debug/ui/historyview" then repeat the slow operations and post the trace here
(In reply to Dani Megert from comment #12) > Personally I also have it enabled, but I heard from people not having an > SSD, that the History view updating can badly slow down the whole machine > while (E)Git provides the input for the history. Is anyone on this bug not > using an SSD and can comment on that? I used a older laptop without SSD. Eclipse starts ultra slow (oh boy) and with this laptop everything was slower. But the History view sync setting did not create any (for me observable) slower interaction.
History synced with the selection a great idea as its performances are good now. Also, the History View should be visible by default in SDK, so more people can understand and use it. IIUC, this bug mentions two items: 1. Link the HistoryView with the selection 2. add the feature containing History View to EPP packages for SDK In reply to Lars Vogel from comment #0) > I think we should customise the Eclipse SDK so that the History View is > automatically synchronised with the current selection. The sync itself can be performed via injection @Inject @Optional void selectionChanged( @Named(IServiceConstants.ACTIVE_SELECTION) Object selection) { if(selection==null) return; this.selection = selection; // perform the sync synchronizeHistoryWithSelection(); } > I have several times seen people (including myself) wondering over the empty > History View. Maybe we can change that preference setting in our Eclipse SDK > build and ask to do EPP the same? Is it just a preference, a setting to enable? - If so, the behaviour above is already implemented somewhere and we have just to set a flag; where? > Opinions? In case we find cases in which objects are slow to be rendered in History, (w.r.t. Dani's comment 12), we could intercept them in the "selection changed", and render them gracefully.
(In reply to Patrik Suzzi from comment #16) > History synced with the selection a great idea as its performances are good > now. > Also, the History View should be visible by default in SDK, so more people > can understand and use it. > > IIUC, this bug mentions two items: Sounds you misunderstood the scope. The sync is already where, you just need to change the default. Also History view is already part of all (relevent) EPPs. The changes needs to be done in GenericHistoryView. Have a look at the setLinkingEnabled method and how it gets its default.
(In reply to Lars Vogel from comment #17) > The changes needs to be done in GenericHistoryView. Have a look at the > setLinkingEnabled method and how it gets its default. Ok, thanks, now I understand. I observed GenericHistoryView#setLinkingEnabled(), and we use the property: IFileHistoryConstants.PREF_GENERIC_HISTORYVIEW_EDITOR_LINKING I'm going to set the default in TeamUIPlugin#initializeDefaultPluginPreferences() so GenericHistoryView#createPartControl() will be initialized by the default.
(In reply to Patrik Suzzi from comment #18) > (In reply to Lars Vogel from comment #17) > > The changes needs to be done in GenericHistoryView. Have a look at the > > setLinkingEnabled method and how it gets its default. > > Ok, thanks, now I understand. > > I observed GenericHistoryView#setLinkingEnabled(), and we use the property: > IFileHistoryConstants.PREF_GENERIC_HISTORYVIEW_EDITOR_LINKING > > I'm going to set the default in > TeamUIPlugin#initializeDefaultPluginPreferences() > so GenericHistoryView#createPartControl() will be initialized by the default. Sounds good, please ensure that it works for the Git team provider. As it is a global setting, it should in this case also work for other team providers.
New Gerrit change created: https://git.eclipse.org/r/70764
Created attachment 260988 [details] Anim Gif: History autosync is quite responsive on a PC with SSD I did some test and it seems quite responsive. It just lags a bit the first time you select a repository
(In reply to Patrik Suzzi from comment #21) History view performance is very dependent on the type of the provider and for providers that have to query a remote server is dependent on how fast or slow that server is. Flipping the default may have a significant negative performance impact on some users. I'm not sure if this is justified by some additional convenience for EGit users. Should this preference be flipped for EGit users only?
(In reply to Sergey Prigogin from comment #22) Currently, it is a global setting, and it uses a single boolean preference and a single button on the UI to activate/deactivate. If we differentiate per provider, we might need to introduce new boolean preferences, and maybe a button with a drop-down menu listing the known providers. Please, see this image as an example: http://i.imgur.com/5nSLAuR.png If we can not agree on a solution here, on this bug, I suggest opening a new linked bug to track the Idea.
Sergey, is this a general concern or can you observe performance problems with your team provider (perforce?) and this setting?
(In reply to Lars Vogel from comment #24) Haven't tried it with my provider (Piper - https://youtu.be/W71BTkUbdqE) yet, but I know that retrieving history isn't particularly fast whenever a server call is involved.
(In reply to Sergey Prigogin from comment #25) > (In reply to Lars Vogel from comment #24) > > Haven't tried it with my provider (Piper - https://youtu.be/W71BTkUbdqE) > yet, but I know that retrieving history isn't particularly fast whenever a > server call is involved. Please update the bug with your test results, once you have the chance to try it out.
(In reply to Andrey Loskutov from comment #10) > (In reply to Lars Vogel from comment #8) > > Matthias/ Andrey, any input from the EGit team on this? > > I have it always on and even with our monster repo I see no performance > issues (on Eclipse 3.8). We should enable it if the platform version is >= > 4.6, since earlier 4.x would cause unexpected refreshes. I must correct me. Working with *multiple* repositories seems to be still an issue. See bug 485743 reported against EGit 4.2 (4.3 contains no changes in that area, so it is still valid).
I suggest we put this on hold until bug 485743 is fixed.
(In reply to Dani Megert from comment #28) > I suggest we put this on hold until bug 485743 is fixed. EGit team started to work on it. Once Bug 485743 has been fixed, we should change the default.
(In reply to Lars Vogel from comment #29) > (In reply to Dani Megert from comment #28) > > I suggest we put this on hold until bug 485743 is fixed. > > EGit team started to work on it. Once Bug 485743 has been fixed, we should > change the default. We've just merged the fix in EGit. Feel free to proceed here.
If no objections I would like to enable this in RC1.
Gerrit change https://git.eclipse.org/r/70764 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/?id=a8d7d8aa410e8dae2bdf78b251ed5043f378b67c
New Gerrit change created: https://git.eclipse.org/r/128033
Gerrit change https://git.eclipse.org/r/128033 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=0a09a1bf06f8c95a5ca1cbaf143caa4f6c7ecd6c
