Community
Participate
Working Groups
I20061129-1340 With the default setting for the maximum file size of the local history (1 MB), the local history crops file contents as soon as the file is bigger than the maximum. This can lead to data loss if the user tries to restore an old version of a file, since the end of the file is silently lost. This can also be observed with the "Undo Delete Resources" support of the Navigator view. Help says: "If the size of the resource exceeds the maximum amount of file size allocated, no local history is kept for that resource". I think that's the way to go. All or nothing. Everything in between is confusing.
I can't reproduce this. I completely agree that local history should be all or nothing, and that is exactly what it should be doing right now. I tried making several modifications to a file > 1MB in size, and it didn't keep any local history for any of these edits. When you say "crop", do you mean you are seeing a file that is exactly 1MB in size in the history if you modify a file that is >1MB in size? The history store certainly does nothing like this. It is potentially confusing that "undo" doesn't always do the right thing. For me, "undo delete" returns me to the most recent revision of the file when it was <1MB in size. If the file was never <1MB, I get the exception as expected that the undo could not proceed because not enough information was available. Susan, perhaps undo should also fail if there is no available IFileState with a timestamp matching the time of deletion? I can't remember if we discussed this case...
The cropped file's size was indeed not exactly 1048576 bytes. It looks like I was confused by the way I created the >1MB text file. I copied some random text and pasted it into the editor repeatedly. In between, I saved the file to see how big it it has become. Since the History view does not show the seconds of the revision time, I must have fallen into the trap that the history silently skips all saves for files larger than the max, but does not remove earlier versions either. John, I agree that the current undo behavior (take the most recent available version) is confusing -- but so is the behavior of the history itself. Instead of not showing such versions, the History view should show a special entry that tells the user that there was a version, but it was not saved because of the file size. Alternatively, it could also remove all older versions to make sure the user doesn't lose data when trying to go back in local history.
Automatically deleting old history entries to avoid the risk of losing user data seems counter-productive. I'm just as likely to delete something that has been saved in the history that they care about. Keeping a special history store entry indicating that the history is missing would be a lot of work - it would require new API, and then all history store clients would have to know how to react to these special history entries. It doesn't seem worth it to me.
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.
