Community
Participate
Working Groups
I've got a simple unshared project in my workspace. I right click and create a new file named "new.txt" and paste some contents into the file. No matter how many times I now edit and save this file, when I show the file's local history I always see exactly two entries: the first corresponds to the current contents of the file, the second corresponds to the file before it existed (it is empty). New entries are never added to the local history, the first entry just keeps getting replaced. I can't even imagine what's going on here...
Turns out I was getting mauled by the default preferences. The default "Maximum file size" of 1MB means no local history for large files. Why is this so tiny?
Since I figured out what was causing the problem I've updated the description. I do think we should consider increasing the default maximum history size, though. 1MB may have been a lot of space 5 years ago, but it's nothing now. I think the default could easily be bumped up to 50MB.
I disagree. Some people like to put their Eclipse workspaces on USB keys and this will not scale right.
I think that the default value is enough for those who use Eclipse for java development. I think that your case is quite rare, so increasing the default size only for a single case doesn't sound good to me. However I will wait for more feedback, before I do something with the issue.
(In reply to comment #4) > I think that the default value is enough for those who use Eclipse for java > development. I think that your case is quite rare, so increasing the default > size only for a single case doesn't sound good to me. > > However I will wait for more feedback, before I do something with the issue. > Well, I can tell you that if you use the WST packages, and are doing XML Development work, that having a hard set limit of 1MB, may be too limiting. Especially with some of the B2B files that can be created by the XML Stanards that are in use and being transmitted by web services. We need to think beyond java, as other types of files need to be locally cached for history comparision purposes, especially as the platform is being used more beyond its initial java development roots. It's not uncommon for me to deal with 2 to 3mb XML files.
If the preference wasn't there I would suggest to add it. In this case, when the preference is there, I would leave it as it is. You are free to change the value to whatever you like. Moreover, I think that more common situation is that you enter a preference page to increase an option of this kind. E.g.: most Windows users extend the size of Recycle Bin as they want to their trash to be kept longer :) In other words, I believe that such options (referring to disk size) should be set to reasonable minimum, but at the same time the user should be able to adjust them to his/her needs.
I stick to my opinion that we should leave the current default size. However the issue for me is that it is not obvious for a user why his/her files are not stored in the history (see comment #0). Maybe we should show a dialog or something informing that changes won't be reflected in the history?
(In reply to comment #7) > I stick to my opinion that we should leave the current default size. However > the issue for me is that it is not obvious for a user why his/her files are not > stored in the history (see comment #0). Maybe we should show a dialog or > something informing that changes won't be reflected in the history? > I agree that for source code development it is probably fine. Not sure how to handle the 20% of cases where this would cause an issue though.
(In reply to comment #7) > Maybe we should show a dialog or > something informing that changes won't be reflected in the history? Could the local history dialog itself be enhanced to say something like "This is a local 1 MB history of <filename>. If this file is sufficiently large, this history size may not be enough and you may not be able to see as many changes as you would like. Please change your <a>history size preferences</a>." as an SWT Link widget to open the preference dialog? Of course, my example is rather verbose, but that's the general idea.
(In reply to comment #4) > I think that the default value is enough for those who use Eclipse for java > development. I think that your case is quite rare, so increasing the default > size only for a single case doesn't sound good to me. > Eclipse is not only a Java IDE and we don't design the platform with only Java in mind. This is fundamental. The USB key case is interesting, but this isn't a problem. If someone wants to tweak their workspace so that it fits on a USB key, this wouldn't be the only preference they'd want to tweak in order to optimize the disk footprint. I still feel that the 1MB limit is too small and it should be increased, but I also agree that some feedback about the local history cropping would be very helpful. I think it would be ideal if there was a dummy entry shown in the history which corresponded to the point where the history was cropped. This entry could simply state "End of history. Local history file too large." This would at least give a clue as to what's going on.
I don't think we should change the default size - we have no idea how people might be using the resource API and what consequence this could have. Perhaps disks are bigger than five years ago, but what if someone's running a builder that modifies thousands of >1MB files? I think Remy's idea of showing something in the history view/dialog is promising. Regardless of what default we set, there can be cases where a user loses history and doesn't know why. We can't prompt whenever such a file is modified because that can happen in some background process and it would be disruptive. However, it's relatively simple to check the file length and compare it to the history size preference.
Adding a comment in the History Dialog is the easiest thing we can do. Adding something to the History View is more complicated. If we want to have a dummy entry for too big file in the history view, we have to store an empty (or with an appropriate comment) file in the history store. The other way is to modify API a bit to afford dummy entries. The other way is just to add a comment in the history view (in the tab header?) when current file size exceeds the max size.
I am no longer involved in Platform Team/Compare development.
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. -- The automated Eclipse Genie.
