Bugzilla – Full Text Bug Listing
| Summary: | Most recent in-IDE edit of a file not stored in the local history => data loss if file is modified externally | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | James Blackburn <jamesblackburn+eclipse> |
| Component: | Resources | Assignee: | Platform-Resources-Inbox <platform-resources-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | markus.kell.r |
| Version: | 3.7 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux-GTK | ||
| Whiteboard: | stalebug | ||
|
Description
James Blackburn
(In reply to comment #0) > Local history should keep the most recent IDE version. By most recent, you mean the *current* revision of the file should be in local history? (In reply to comment #1) > (In reply to comment #0) > > Local history should keep the most recent IDE version. > > By most recent, you mean the *current* revision of the file should be in local > history? No, I mean the last version saved in an Eclipse editor. Having changed a file externally, there doesn't seem to be a way to get back eclipse's last saved version. This may be a UI artifact as afaics every save calls through to the history store. Haven't dug too deeply into where the issue might be... Ok, just to be clear, when a file is modified in Eclipse, the *previous* contents are moved to local history. There is nothing in the local history for the current file contents after saving in Eclipse. I'm not sure if I'm making sense in explaining it... (In reply to comment #4) > There is nothing in the local history for > the current file contents after saving in Eclipse. I'm not sure if I'm making > sense in explaining it... That does make sense and seems to be exactly what I'm seeing, having re-read bug 10589 this does seem to be a similar request. It's great to save the previous version, but the current version should be saved too or there's a sort of off-by-one as external operations can cause the most recent internal change to be lost. For example, the case I had today, was a user doing a git reset --hard causing a merge to be aborted and their files to be reset to HEAD. They expected the most recent saves they'd done in the IDE to be in the local history. Instead they had the most recent-but-one in the local history. Ah, I see that the behaviour also matches the JavaDoc. I think the confusion arose because I can see the most recent version of the file in the Local history view, indistinguishable from the previous revisions there. As the other history elements are immutable, I thought the most recent one would also be immutable... Would it be a bad thing to add the history to the state after a save as well as before: getHistoryStore().addState(target.getFullPath(), store, fileInfo, false); ? I guess there could be performance implications, but in the usual case the previous version has already been added at the end of the last setContents, so should be optimizable to a NOP. 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. |