Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[platform-compare-dev] Compare/Merge/Patch Issues 
Hi,
I'd like to get some feedback on the Compare/Merge/Patch functionality of
Eclipse's Compare plugin.

To get things started I collected different approaches of how to integrate
Compare/Merge into the Eclipse platform and Java tooling and listed (some)
pros and cons.

(See attached file: CompareIssues1.html)

In the next couple of days I would like to find a story that is more
consistent than what we have today.

Thanks in advance for your input,

--andre
(See attached file: CompareIssues1.html)
Title: Compare/VCM Issues

Compare Issues

How is "Compare/Merge with Stream/Version/Patch/Each Other" presented?

The answer to this question affects the UI of the "standalone" functionality of the Compare plugin (Compare with Each Other/Replace with local History etc.) and what toolkit components the compare plugin will offer in the future (e.g. CompareEditor vs. CompareView etc.).

I see the following four alternatives for presenting "Compare" in the UI. If you see more please let me know!

  • Editor
    • like "Compare With Each Other" today
    • Fully buffered, only one "atomic" Save
    • Benefits:
      • Best fit for "merging", that is editing a workspace resource
      • Standard Edit menus are available for merging
      • Simple conceptual model: Compare takes snapshot and opens it in editor
      • Editor is buffered. User is never forced to save until she has merged everything.
        • "Undo all changes" would be easily possible
      • Multiple compares (multiple snapshots) possible
    • Problems:
      • Space is tight in editor: e.g. Compare with versions: table with versions fills upper half of editor.
      • Editor seems overkill for method level Replace/Compare with local history
      • Compare editor is not automatically reused
      • When merging into a local resource: what to do with resources that are aleady modified in an open editor?
      • how to update the compare tree viewers within a compare editor: should resolved changes completely go away? (the user would know when he is ready to commit all changes). However, if he wants to undo some changes he needs to get back the "hidden" changes. (My first version had a special category "resolved" where all resolved changes were moved) Another approach is to use a special icon (or no icon at all) for resolved changes. (A nice solution would be to dim all resolved items, so that only the unresolved items would stand out).
  • View
    • like "Synchronize with Team"
    • Benefits:
      • "fast views" allow for "full screen" compare viewer
      • more flexibility in rearranging
      • automatic reuse
      • non-modal
    • Problems:
      • in case of content merging a part of the compare view is more like an editor (with save!)
        • if not buffered every save has immediate effect on workspace
          •  triggers an auto build and makes me wait before I can proceed
          • "undo all changes" more difficult because user can save other editors while merging (and saving) resources in synch. view.
        • buffered view seems strange: why not use a compare editor then?
      • toolbar and menubar actions are not available even if the merge editor could use them
  • Dialog
    • like "Replace with Local History"
    • Benefits:
      • works well to browse (and compare) small pieces of code (methods)
      • is modal: no concurrency problems
    • Problems:
      • if merging required, dialog becomes an editor:
        • where is the toolbar?
        • where are all the standard actions (undo, redo, etc.)?
  • Perspective
    • Compare editor parts are mapped onto "Compare Perspective"
      • custom Navigator for resource changes *or*
      • a Marker view (similar to Search result view) which lists the resource changes
      • Editor for content changes
      • Outliner for structural changes within content
    • Benefits:
      • user can arrange views within perspective.
      • makes good use of screen real-estate
      • Marker view would avoid the problem with manually expanding a tree; however the changes cannot be longer viewed as a resource tree (selective releases and catchups are harder because I cannot select hierarchically).
    • Problems:
      • context switch
      • multiple open merge editors: user might get lost.
      • It is no longer clear when a "merge" is a finished? All Markers resolved? All editors touched?

My Proposal:

  • no Compare perspective: I don't like perspective switching ;-)
  • no views: because they cannot use menubar and toolbar actions even if they behave almost like an editor.

    •  
  • Compares with merge capabilities should use an Editor. However these problems must be addressed:
    • a user preference for buffered/non-buffered mode of operation:
      • users that have autobuild on want to have buffered compare editors because they want to build only once
      • careful user want to be able to merge everything before releasing a single change to the system
      • other use can release and catchup (save) at all times
    • Compare editors should be reused by default (like Synch Views).
    • there should be a similar mechanism like "Fast View"
    • if a compare editor becomes empty it should be closed.
    • a Compare editor should is only used to browse the result of a compare operation not its input. Therefore I would suggest to move the version table of "Compare with Version" into a seperate dialog.
  • Small (method level) compare/merge should use a dialog where the user can compare and replace method editions. If she wants to merge them it should be possible to open a "normal" Compare Editor from the "Replace with local History" dialog. This approach avoids that we need "real" editors inside (modal) dialogs.

Back to the top