[platform-compare-dev] Re: Compare issues

[Jean-Michel_Lemieux@xxxxxxx]

>Well, seems like this is a pretty quiet mailing list... if there's
>anybody actually listening,

Listening, but not contributing enough to the discussion :<

> If you have some more time may be you can give me some feedback for my
> posting "Compare/Merge/Patch Issues". I would like to know how Compare/Merge
> functionality should be presented: as an editor, a viewer, a dialog,
> or looseley coupled views and editors in a perspective.

I don't like perspective switching either - I've actually integrated my debug/java views
into one perspective and love it, especially with the improved keyboard support! Anyway, I have a feeling that compare support should be available in both views and editors. I can understand the problem with supporting merges in a view, so maybe merging and comparing should be separated? For example, in the sync view you can peruse file changes and browse the actual differences and conflicts. However, if you decide to start a buffered/transactional *manual* merge (as opposed to either performing an auto-merge<g> or a non-buffered merge) a transactional/buffered merge editor should be used. This would allow the following:

- buffered merge operations are not be allowed views.
- auto-merge and non-buffered merges are allowed views.

Ideally, I would like the sync view to remain a view.

> I have some more minor items but this should be a good start for
> discussion. Please post them here too!

The milestones for 2.0 are quickly approaching, and I would like to ensure that some of the features we have discussed do not get lost. Should we start adding these as PRs so that they can get tracked? Here are my top issues...

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

What is the status on this? I would love to be able to qualify conflicts better in the sync view.

2. Supporting auto-merges?

3. When merging a file I'm never sure about the state of the merge, how many adds/deletions/conflicts are left ect. It would be great to have a mechanism with the compare editors to show the relative overview of the sync between the two files. As merges occur you could quickly see what you've done.

4. Did I mention auto-merge <g>... If this is available, a toolbar button must be added with existing the "copy left to right" items. 

5. Add keyboard shorcuts for merging, move to next change and then there must also be shotcuts for merging option given the higlighted change.

Is it too late to have any of these items addressed in 2.0?

Jean-Michel