Bugzilla – Full Text Bug Listing
| Summary: | [History] Set Maximum Size for a given workspace's local history | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | James Blackburn <jamesblackburn+eclipse> |
| Component: | Resources | Assignee: | Platform-Resources-Inbox <platform-resources-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P4 | CC: | markus.kell.r, mober.at+eclipse, Szymon.Brandys, tomasz.zarna, wb-rel |
| Version: | 3.3.1 | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | All | ||
| Whiteboard: | stalebug | ||
|
Description
James Blackburn
James, I'm not sure how would you like to combine maximum local history size for each file with the global option you're suggesting. Should the the limit of an individual file be ignored when there is still some space to use according to the "global limit" ? Well the two options are somewhat orthogonal; so yes I think an overall global limit could override both the max time to keep and individual file size limits. As things stand the user has no control over the total size of the .history directory (my current Eclipse workspace is using 256MB), but does have control over the maximum history for a given file which is overall less useful, I think. From my point of view I would like to keep, say, 100MB worth of history with the oldest items being purged as the limit is reached. I think this probably fits better with way people work too. You work in a particular area of code -- and you value fine granulatiry of history for those files -- then you check your code into source control and move onto another region where you have the same expectations. It seems slightly crazy that there is no global cap on history usage which can play havoc with quotas etc. This would also help with bugs such as Bug 208162 which complains about the cap on an individual file's history. I suspect that a global limit is much more important to people than a per-file limit, which, at the end of the day doesn't mean all that much. Bug 66370 says that all the history items are iterated over at workspace close, so it may be reasonable to defer history pruning to then? I'm sure that the global history size, the single file history size and max time to keep can work together. We should keep the the single file history size (see the comment #11 for the bug 208162) and it should work as it does now, however if the global limit is met the history should be purged (e.g. the oldest entries should be removed) CQ:WIND00181490 As an interesting variation of this theme, we have a customer who wants to set a local history max size of 0, i.e. disable local history entirely. They are working on sensitive data, and when a developer leaves a computer, they want to make sure that no traces of any edited data are left on that computer. At the moment (Eclipse 3.6M7), the "Local History" Preference page does not allow setting a max history size 0. On the other extreme, we have a different customer who is so scared of a hard disk crash that they would like to have local history stored on a configurable location outside the local .metadata (see bug 34076 comment 55 -- they claim that their previous editor Codewright provided them with a feature to configure the editor backup location to point to a remote share that's backuped). 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. If the bug is still relevant, please remove the "stalebug" whiteboard tag. |