Bug 10680 - Ensure local history is used for UI operations
Summary: Ensure local history is used for UI operations
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 2.0   Edit
Hardware: All All
: P2 normal (vote)
Target Milestone: 2.0 M4   Edit
Assignee: Lynne Kues CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 10696
Blocks:
  Show dependency tree
 
Reported: 2002-03-04 10:47 EST by Nick Edgar CLA
Modified: 2002-03-12 16:00 EST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Edgar CLA 2002-03-04 10:47:28 EST
Build 20020228

We need to ensure all destructive operations done by the UI are recoverable 
using the local history.

We also need to make it easier to recover deleted files.  The current UI for 
this is non-obvious (you have to recreate the file first in order to get at its 
local history).

This is a P1 plan item, scheduled for M4.

The core team is adding API:
- to add the keepHistory flag in places where it's missing (e.g. 
IWorkspace.delete, IResource.delete)
- to make discovering deleted files easier (something like 
Container.findDeletedFiles(int depth))

See also:
Problem with D&D in UI: bug 10232
Core feature request to add current contents to history: bug 10589
VCM improvements for local history: bug 8479
Comment 1 Nick Edgar CLA 2002-03-04 11:10:46 EST
The UI for local history is provided by the Compare component.
Filed bug 10682 against Compare for the deletion UI work.
This PR covers just ensuring that the UI operations use the local history 
wherever needed.

Also, a correction to the above.  This is not a P1 plan item.  It is on the 
plan for 2.0 as an uncommitted item (it's still important though).
Here is the relevant paragraph from the plan:

Improve local resource history. 
The workspace local resource history mechanism keeps recent copies of modified 
or deleted files in order to help save the user from losing data in common 
situations. In 1.0, many UI actions that the user would reasonably expect to 
grow the history are not doing so, and there is no obvious way to recover a 
saved state of a file once it has been deleted. We plan to make the history 
facility more reliable and helpful for 2.0.
Comment 2 Lynne Kues CLA 2002-03-04 16:34:48 EST
From UI point of view need to look at save, delete, rename, and replace 
(including import) operations to make sure history is being saved.  Rename, at 
the least, can be tracked as a delete operation for the old file.  Currently if 
you rename a file, you'll lose its history.  Similarly, if you  rename a 
container object, you'll lose the history for all the files in the container.
Comment 3 Nick Edgar CLA 2002-03-05 10:33:14 EST
Also need to consider import and drag-and-drop.
Comment 4 Lynne Kues CLA 2002-03-08 16:32:54 EST
Import and DND problems fixed in 10232.
Comment 5 Lynne Kues CLA 2002-03-11 11:54:33 EST
Local History Rules:

Move/Copy ==> if the operation creates a new resource, the history from the 
moved/copied item is NOT carried over
Move/Copy ==> if the operation overwrites an existing resource, the contents of 
the resource to be overwritten is added to the local history before the 
move/copy operation and all other local history entries for the resource to be 
overwritten remain as is
Import ==> if the operation overwrites an existing resource, the contents of the 
resource to be overwritten is added to the local history before the move/copy 
operation and all other local history entries for the resource to be overwritten 
remain as is
Save ==> the pre-save contents of the resource are added to the local history 
before the save operation

The above operations have been verified or fixed to work as stated.  

Still need to work on/verify the following operations:

Refresh from Local ==> Currently, this operation is destructive (i.e., you can 
lose work) since the pre-refresh contents of the resource are not added to the 
local history.  Handling this would require new CORE API.
Rename ==> If rename operation creates a new resource in the SAME containing 
resource (i.e., the container of the item that is being renamed), the history 
will be carried over.  If rename operation creates a new resource in a different 
containing resource, the history from the item that is being renamed is NOT 
carried over.  If rename operation overwrites an existing resource, the contents 
of the resource before the operation will be added to the local history and all 
other local history entries for the resource to be overwritten remain as is.
Delete ==> Need to ensure that history is being kept for all delete operations.
 
Comment 6 Lynne Kues CLA 2002-03-12 12:14:37 EST
Correction on rename operation behavior:  

Rename ==> If rename operation creates a new resource, the history from the 
item that is being renamed is NOT carried over regardless of whether or not it 
is in the same containing item.  If rename operation overwrites an existing 
resource, the contents of the resource before the operation will be added to 
the local history and all other local history entries for the resource to be 
overwritten remain as is.

Verified rename operation working as stated above.
Comment 7 Lynne Kues CLA 2002-03-12 13:06:06 EST
Went through senders of all operations in IFile, IFolder, IResource, and 
IWorkspace.  Fixed/verified that all UI operations are specifying keepHistory 
when applicable.
Comment 8 Lynne Kues CLA 2002-03-12 16:00:20 EST
Released changes.