Difference between revisions of "Compare"

From Eclipsepedia

Jump to: navigation, search
m
Line 12: Line 12:
 
== Save Life-cycle ==
 
== Save Life-cycle ==
  
Saving properly in the Compare framework has always been a bit of a black art. The reason for this is the layered nature of the Compare framework. For a local file, the layers are:
+
Saving properly in the Compare framework has always been a bit of a black art. See bug [https://bugs.eclipse.org/bugs/show_bug.cgi?id=125538 125538] for a description of one way of making it work. The reason for this is the layered nature of the Compare framework. For a local file, the layers are:
  
 
# The file (instance of IFile)
 
# The file (instance of IFile)
Line 21: Line 21:
  
 
# save is called on ContentMergeViewer
 
# save is called on ContentMergeViewer
# save obtains the content from the left side Document in the content merge viewer (problem: content is assumed to be a byte array).
+
# save obtains the content from the left side of the content merge viewer.
 
# content from document is passed to the viewer content provider (instance of MergeViewerContentProvider)
 
# content from document is passed to the viewer content provider (instance of MergeViewerContentProvider)
 
# the content provider calls saveContent on the left typed element of the compare input if the compare input is an IEditableContent).
 
# the content provider calls saveContent on the left typed element of the compare input if the compare input is an IEditableContent).
 
# the ResourceNode updates its buffer to contain the new content and fire a change event
 
# the ResourceNode updates its buffer to contain the new content and fire a change event
 
# if you want the file to be saved, you would need to listen to that event and call commit on the ResourceDiffNode
 
# if you want the file to be saved, you would need to listen to that event and call commit on the ResourceDiffNode
 +
 +
There are a couple of observations that can be made about this:
 +
 +
* The ContentMergeViewer save lifecycle only works with byte oriented content.
 +
* Both the document in the TextMergeViewer and the ResourceNode buffer the contents of the file (that means there are at least two in-memory versions of the file for each side (and the ancestor if there is one).
 +
* the save method of ContentMergeViewer is really a flush.
 +
 +
I have entered bug [https://bugs.eclipse.org/bugs/show_bug.cgi?id=150526 150526] to request that the use of BufferedContent be avoided for remote files.
 +
 +
I have reopened bug [https://bugs.eclipse.org/bugs/show_bug.cgi?id=114 114] to consider linking resource nodes (and also possibly IStorage nodes) with underlying file buffers so that in-memory content is shared between editors.

Revision as of 12:05, 13 July 2006

In the 3.3 release, we are planning on working on some of the outstanding defects that have accumulated for the Compare component. Some of the areas we plan on looking at are:

  • Asynchronous loading and update of compare editors
  • Improving the save life-cycling
  • Improving difference and change Navigation
  • Use of text buffers when comparing local content
  • Upgrade to use the new Commands/Key bindings framework
  • Switch to using the History view for local history operations (Compare/Replace/Restore)

The following sections outline some thoughts on each of these areas.

Save Life-cycle

Saving properly in the Compare framework has always been a bit of a black art. See bug 125538 for a description of one way of making it work. The reason for this is the layered nature of the Compare framework. For a local file, the layers are:

  1. The file (instance of IFile)
  2. The ResourceNode (instance of IEditableContent)
  3. The TextMergeViewer

Assume you have an merge viewer open and edit the left side. A save is triggered by a Save operation or selecting another element to edit. What happens in this case is the following:

  1. save is called on ContentMergeViewer
  2. save obtains the content from the left side of the content merge viewer.
  3. content from document is passed to the viewer content provider (instance of MergeViewerContentProvider)
  4. the content provider calls saveContent on the left typed element of the compare input if the compare input is an IEditableContent).
  5. the ResourceNode updates its buffer to contain the new content and fire a change event
  6. if you want the file to be saved, you would need to listen to that event and call commit on the ResourceDiffNode

There are a couple of observations that can be made about this:

  • The ContentMergeViewer save lifecycle only works with byte oriented content.
  • Both the document in the TextMergeViewer and the ResourceNode buffer the contents of the file (that means there are at least two in-memory versions of the file for each side (and the ancestor if there is one).
  • the save method of ContentMergeViewer is really a flush.

I have entered bug 150526 to request that the use of BufferedContent be avoided for remote files.

I have reopened bug 114 to consider linking resource nodes (and also possibly IStorage nodes) with underlying file buffers so that in-memory content is shared between editors.