Community
Participate
Working Groups
This is a generalisation of JDT Bug 571622 for platform.resources. I observed that currently both JDT and Xtext do write history files for files they derived. Both Projects already voted that this should not happen. Can we change it in generally in platform.resources instead of microfixing every project? That would mean we would ignore IResource.KEEP_HISTORY if IResource.isDerived(). Note that KEEP_HISTORY is already sometimes ignored which is decided in HistoryStore2.isValid(IFileStore, IFileInfo).
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.resources/+/180356
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/180357
Created attachment 286338 [details] Screenshot of proposed Configuration Dialog.png added Screenshot of proposed Configuration Dialog.
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.resources/+/180356 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?id=fc5d88b24c1997a1c93adb3e206a6a390d2e8d11
Jörg, please add to N&N. Did you measure the performance improvements? If yes, please share here in the bug report.
(In reply to Lars Vogel from comment #5) > Jörg, please add to N&N. Is there some guide how to do so? I did not do such yet.
(In reply to Jörg Kubitz from comment #6) > (In reply to Lars Vogel from comment #5) > > Jörg, please add to N&N. > Is there some guide how to do so? I did not do such yet. The repo contains a guide, see https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/180702 for an example. Can you also answer the second question: Did you measure the performance improvements? If yes, please share here in the bug report.
(In reply to Lars Vogel from comment #7) > Did you measure the performance improvements? I did not do any measurement yet. I know the HistoryStore2.addState() used to take 9sec of our full builds. That SHOULD be totaly gone now. I will try a measurement again as soon as the IBuild of the UI is available to verify if that is solved and configurable. However this change is not only for performance. The waste amount of history files does also either flood the disk or - if limited - will reduce the size of useful history.
New Gerrit change created: https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/180874
Gerrit change https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/180874 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=038b67f4a993f2fcd3976962e941a8d4c76cef6c
interestingly this now shows up as failing Xtext/Xtend tests https://github.com/eclipse/xtext-xtend/issues/1198
how to change this programmatically org.eclipse.core.internal.resources.WorkspaceDescription.isKeepDerivedState() org.eclipse.core.internal.resources.WorkspaceDescription.setKeepDerivedState(boolean) seems to be asymetrically overriden in org.eclipse.core.internal.resources.WorkspacePreferences.setKeepDerivedState(boolean)
(In reply to Christian Dietrich from comment #12) > how to change this programmatically The UI in FileStatesPage.performOk() uses ResourcesPlugin.getWorkspace().getDescription().setKeepDerivedState(boolean); Later the actual WorkspaceDescription.keepDerivedState is updated via org.eclipse.core.internal.resources.WorkspacePreferences.synchronizeWithPreferences(String) which is registered as listener in WorkspacePreferences constructor.
Somehow this does not fix out test.
(In reply to Christian Dietrich from comment #14) > Somehow this does not fix out test. Where can i see the commit which tries to fix it?
https://github.com/eclipse/xtext-xtend/compare/cd_issue1198 i dont see the WorkspacePreferences.synchronizeWithPreferences called
org.eclipse.core.internal.resources.WorkspaceDescription.setKeepDerivedState(boolean) calls into the non preference one. so there also no listener will be called
using the internal api == downcast to workspace and use internalGetDescription seems to help val d = (ResourcesPlugin.getWorkspace() as Workspace).internalGetDescription() d.setKeepDerivedState(keepLocalHistory);
> using the internal api == downcast to workspace and use ugly. This should work: IWorkspaceDescription description = ResourcesPlugin.getWorkspace().getDescription(); description.setKeepDerivedState(keepDerivedState); try { //As it is only a copy save it back in ResourcesPlugin.getWorkspace().setDescription(description); } catch (CoreException e) { throw new RuntimeException(e) }
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/180357 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=7510f07540a1fd657dbcdb1a6563da54f8e0f465
*** Bug 571622 has been marked as a duplicate of this bug. ***
*** Bug 411012 has been marked as a duplicate of this bug. ***
Currently, disabling the option "History derived files" prevents only that when directly editing a derived file, new states are stored in the local history (stored in .metadata/.plugins/org.eclipse.core.resources/.history/**). It does not prevent that when copying a file from non-derived to derived (e.g. when the Java project builder copies non-Java text files from the source folder to the output folder) the derived file gets the local history of the source file (stored in .metadata/.plugins/org.eclipse.core.resources/.projects/**/history.index when exiting the IDE). So, derived files still have a local history referring to file states created by the non-derived source files when they are copied from non-derived files (which I guess is the most common case) and not edit directly (which I guess is a corner case). Maybe it would be a memory/speed improvement if disabling the option would also prevent copying of the history table when copying a non-derived file to a derived file. Files not having the derived attribute but located in a folder with the derived attribute, should also be handled as derived (which is currently not the case and might be an issue when generating code in the output folder).
(In reply to Holger Voormann from comment #23) > It does not prevent that when copying a file from non-derived to derived > (e.g. when the Java project builder copies non-Java text files from the > source folder to the output folder) the derived file gets the local history > of the source file I'd even say that it is a bug if copies get their history from source. Please file a separate bug about that.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/185575
