Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-compare-dev] Compare issues from VCM perspective

Thanks a lot for this first batch of feedback!
Here are some first answers:


-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.

Yes, I would love to have something like the Unix /etc/magic stuff.
Right now the Compare plugin is probably better than in earlier versions since by default it shows everything as text unless it has lines longer than 2000 characters. However this heuristic shouldn't be used to detremine whether a file is checked into CVS as text or binary. The most important thing here is that a Compare plugin does not have to introduce its own registry because this will immediately go out of synch with other registries. So for example if a new editor is added for a specific file type a readonly variant should be registered with the compare plugin so that an 'Add from local History' dialog can use it. This is troublesome. It would be much better if an EditorPart could be used in a dialog context as well (see discussion on Eclipse Corner). Even better would be if the two-side compare viewer could use any (text) editor as one of its two panes.


-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.

Yes, it is strange if you have both paradigms. I started the compare stuff with the buffered appraoch for several reasons (elaborated in the separated document posted several hours ago). I would love a system where I can merge hundred files in a sandbox without triggering any intermediate autobuilds and the chance to undo everything (or to not commit any changes in the first place).


-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.

Yes, we (I :-) can definitely improve things here.
I will have to delve into that in greater detail....


-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)

Yes, I had this option in VAME.
I even think it should be possible to do this without any Compare UI.


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

No, problem. Would be Friday OK? :-)


-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

I think I know the relevant algorithms in this area and I firmly believe that doing this on a line by line basis is not fruitful (and I know of no good UI to communicate the changes to the user). However, I believe that using semantic information of the text leads to better results. Try to swap to methods in Eclipse and use the textual compare viewer. It won't show you that the code was swapped. Double click on the changed resource and the structure compare viewer will show you nothing to indicate that the file has no semantic changes. Yes, I agree the UI can be improved but it is a start. The "light bulb" button even tries to detect simple renames and signature changes. This would not be possible on a textual (that is line by line) basis, where the semantic structure of the given files isn't taken into account.


-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.

Yes, improvements are always possible.
Just file problematic cases as bug reports.


-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 timeout issue will be fixed. Actually the problem is not finding the differing ranges of text but finding the token differences within these ranges. For example if two very similar files were reformatted by changing the indent of each line there is basically one big change covering the whole file. If a token compare is performed on this huge range, I will run into the absurd 20 sec. limit. The 20 sec. limit is there because I couldn't introduce a restartable timeout mechanism with an API change. May be enabling the "ignore whitespace option" by default would help in many cases.


-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.

Hey, we have the CompareEditorInput because VCM switched the architecture from dialogs to editors to views :-) I tried to find an pragmatic abstraction that could be used equally well with a Compare Editor, a View Part or a Dialog without turing my stuff always upside down. Yes, it is a Blob. But some call Blobs 'components' or just a 'plugins' :-) Look at all other plugins in Eclipse. There is always this kitchen sink plugin class. On the other side CompareEditorInput is only the tip of the iceberg (one class out of how many?). If we can agree on a single way of using Compare (see separate document) I'd be very happy to replace it with a bunch of clear and very specific abstractions :-)


-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.

Yes, I completely agree. I have the same problem because Java Compare (me) is a client of platform Compare (me) too. So I understand what you are talking about :-) I will use the same mechanisms that are used in similar cases, like the context menu in the editors outline view. However in 1.0 we had to use hacks in many places because no acceptable architecture was in place.

-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.

Yes, it was on by default in the first version of the Compare plugin. I had to turn it off because of a PR filed by users who didn't want to wait for loading the file from CVS in order to do the structure compare..


-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.

Yes, give me more details and I will try to come up with a reasonable solution. Right now you have the option to switch from three-way to two-way compare.


-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.

Yes, I completely agree. See my document discussing the issues of the various variants. We should come to some agreement here because this decision impacts lots of the other issues, too. Just add to my list of pros and cons and tell me what you would do if you had to integrate compare/merge in a consistent way into Eclipse. I'm open for every proposal.


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

Please post them here too!

Thanks a lot James!
I very much appreciate this kind of feedback.

--andre


Back to the top