Community
Participate
Working Groups
I just had a major "whoops" and have been trying to resurect my module with Eclipse's Local history. It's been a god-send, but it's also led me to believe that Local History needs a couple of minor improvements. 1. Assume a file A. it's original contents is A. After a modification and a save its contents is A', and after a subsequeny modification and save its contents is A''. It appears that A is only saved to local history upon the creation of A' (ie/ modification and save of A), and A' is only saved to local history on the creation of A''. It would be much more useful for recovery if instead of adding the old version of the file to local history (A), you added the newly created version (A'). The scenario I'm specifically thinking of is accidental file deletion. 2. Follows from 1. Adding to local history the new version of any files that get replaced on a "refresh from local". Thank you, Marco Qualizza
Marco, I'm curious as to what the "whoops" was. Is there an area of the UI that is prone to causing your "whoops" (separate from improving the support for recovery)? Deleting a file should add the previous contents to the local history, although it would be safer to do as you suggest, especially since files can be deleted directly from the filesystem with no chance for Eclipse to intercept it. I'm curious about your particular case though. How were the files deleted from your workspace? And did the latest edition not appear in the local history?
See bug 241 for another example of why it should work as suggested.
*grin* that's why I didn't include any information on what caused the lossage... It wasn't an Eclipse error or problem, it was simple luser-ness on my part. Through a convoluted process of renaming directories, checking out a differnt version of the modules with WinCVS, and emptying my recycle bin at the end of the evening, I lost my work. This all took place outside of Eclipse. Eclipse has been fundamental in saving me a week's worth of rewriting and I'm *extremely* grateful, but there are a few factors which weakened it's ability to save me even more trouble: 1. Many of my classes, esp. the smaller classes, were written in one pass with no editting afterwards. Eclipse was thus left without a change history. 2. I also changed many JSPs, which I do with an external editor (UltraEdit). Now, the JSPs are part of my project, so Eclipse did pick up the changes on a refresh from local, but unfortunately it didn't store the changes since I didn't do the editting through it.
1). We do not plan to agressively store file contents in the local history on the first setting of file contents (creation). 2). In the case of a refresh-local, we don't know the old content, only the new content that it is being replaced with. And since we don't store the current content of resources in local history, this content will not be saved until a change is made.
When you say "we don't plan", do you mean pre-2.0, or do you mean it's not planned at all? If not at all, may I ask what made you decide that way?
This will not be fixed for 2.0. Aggresively populating the local history with every file in your workspace the first time you create it, would be a bad idea since I believe a typical user's workspace contains a couple of projects that they are working on (which you want in history) and the rest of the projects that you are referencing (which you don't want in history) Thus a notion of a "primary" resource or something along those lines would be required in order to differentiate between those which you want stored in history and not. This would require a major architectural change. Some of the other downsides of aggressively moving current file contents to the local history are size and time. Basically each resource in your workspace is to be duplicated in local history so if you have a big workspace, then you have a big local history even before you begin. And depending on your flushing setting, that could mean you are busy flushing the local history when you are first creating a project. Also note that it would mean the double-time of creating the file in 2 places when you first bring it into the workspace. The current strategy is that local history contains only files which you have modified. Of course this means that we can't help people who make changes outside of Eclipse (on their resources in their workspace). All that being said, Eclipse is an open source project and we welcome contributions so if you would like to look into the problem and submit a patch, I would be interested in reading it.
*** Bug 24249 has been marked as a duplicate of this bug. ***
