[platform-compare-dev] Compare issues from VCM perspective

["James Moody/OTT/OTI" <James_Moody@xxxxxxx>]

Hi Andre and all...

Here is a collective list of our (VCM team) current issues with the 
compare framework. This list was compiled in collaboration with 
Jean-Michel and JohnA (who's an honorary VCM team member for the purposes 
of this discussion). Thanks to both of you for your input.

If anyone would like to spawn a discussion on any one of these items, or 
needs more information, please reply to the list.

In no particular order:

-Better detection of Binary/Text file types. This one is particularly 
interesting from our perspective because the VCM would also be a consumer 
of a hypothetical core mechanism to determine file types (so we know 
whether to store it as ascii or binary in the repository). If we go the 
file extension route, we would have a hashtable somewhere (core) to which 
plugins could contribute known types (e.g. Java plugin says .java files 
are text, .class are binary). If we go the magic route, we determine the 
file type based on its contents (magic header bytes) rather than file 
extension, in the same way unix does.

-The save mechanism is kind of strange. You have the concept of 'save' for 
the whole editor (and likewise, dirty indicators), but you can also enable 
save actions on the popup menus for the individual editors, which is a 
separate mechanism. The root of this problem is that there is an editor 
containing multiple editors.

-Compare currently has only one kind of conflict, but VCM talks about 
conflicts in a different way. The builder of the tree (us) is responsible 
for determining whether nodes are in conflict, but our criteria for 
conflicts (timestamps, sync info) is different than what the compare 
framework considers a conflict (contents). There are different classes of 
conflicts; (a) contents are equal (pseudo-conflict) (b) contents differ, 
but can auto-resolve all changes (c) contents differ, but can not 
auto-resolve all changes. We need to expand the compare editor's idea of 
conflicts.

-UI nit: there really should be a way to auto-resolve all possible changes 
in a conflicting file (i.e. automatically take all incoming 
non-conflicting changes)

-N way merges (Jean-Michel can probably explain more about this)

-Better support for showing blocks of text that have moved in a file; this 
is next to impossible given the current strategy of using lines and blocks 
to show changes (you don't want to have lines crossing) but this is a 
pretty common case

-Some seemingly simple cases of changes could be better parsed by the text 
differencer; sometimes it doesn't show what you'd expect for some common 
cases.

-Performance. Loading large files (SWT's OS class, for example) results in 
'cannot reasonably determine changes in 20 seconds'. The VCM usage of 
compare has some performance problems that may be related to both VCM and 
Compare doing redundant work.

-The compare editor input is a Blob[tm]. It is input for an editor, but it 
also creates widgets, and is a runnable. These classes get quite large 
quite fast and there is not feeling of well-defined functionality for it. 
This functionality should be spread over multiple classes.

-Some situations where a compare user (e.g. us) wants to contribute 
actions to the popup menus, tool bars, etc. are problematic; we have hacks 
in at least one place to make this happen. I don't have the PR handy but I 
can find it.

-The structure viewer is almost a hidden feature. If I hadn't accidentally 
double-clicked once I never would have discovered it. It should be made 
first class, either by adding a toggle toolbar item or something like 
that.

-3 way/2 way compare. This is the case where we have no base, but we know 
the base timestamp. Jean-Michel can explain more about the problems 
associated with this.

-In general there is confusion caused by the fact that the compare 
framework is used both in a view (sync view) and in editors (compare with 
version); these differences should be reconciled. The problems with this 
also relate to the fact that there is in actuality two views and two 
editors inside it, all crammed within a view or an editor. This brings 
about what Steve calls the 'keyhole effect'; that is, a lot of information 
in a very small place in the workbench.

I have some more minor itemsbut this should be a good start for 
discussion.

james