Why change it? Because there were many open bugs relating to the synchronize view, there was no public API for repository providers to use it, and we felt that we could to better.

Problems

In brackets is the 3.0 milestone build where the problem has been addressed.

Structure compare part has many usability problems

1. The problem is that the things you are interested in (the leaves of the tree) are continually scrolled out of view and separated by a great distance when the tree is expanded, making it hard to see at a glance what has changed. It also makes multi-selection operations very painful, for example comitting a set of related files that should have the same comment. (12453, 16249) [M2]
2. There are several also several expansion/selection usability problems with the part. (35187, 33041, 4931, 5431, 20847, 27237, 16249)
3. Synchronize view modes (filtering) and conflict workflows must be improved (10556, 9451, 139, 19712) [M2]

Finding the outgoing changes requires a long running operation

To commit outgoing changes you have to hit the server. This is really painful since the list of outgoing changes can be determined without considering the remote files. [M2]

Synchronization view doesn't fit with workbench view/editor paradigm

The sync view is essentially an editor and a view combined. Unfortunatly they don't quite work as any other view/editor combination in the workbench.What would happen if we split the structure compare away and made that a view on the sync states of all resources in the workbench and then allowed opening a compare editor (basically the bottom portion) when merging or viewing changes was required? [M2]

Background fetching of remote state

Currently when a project is synchronized the complete remote tree is fetched and a progress dialog is shown. The user can't perform any other operation while the remote tree is fetched. There is no reason why this couldn't be fetched in the backgroup without blocking the UI and would allow an awareness of what other people in the team are working on and help reduce the time needed to find out what others are doing. [M2]

Java text merge editor isn't real

Would like to use real editors for merging instead of the neutered ones currently used. For example, the java editor shown in the sync view looks real (e.g. syntax coloring) but is a scaled down java editor. This causes integration and context problems because it is very useful to try and write code in these editors without resorting to opening the file with the real java editor. Then going back to the sync view only to find that the file hasn't refreshed.

Compare editors (merge/compare) versus sync view

The terminology and look and feel of the merge editor and sync view is different. Basically a merge is the same as synchronizing except for the fact that you can't commit changes. Merging is already a tricky operation and having a conflicting usage model between the sync and merge makes it even harder. (35577) [M2]

Comparison criteria is not well integrated into compare

The comparison criteria that is used to calculate the sync state is hidden from the user and it isn't obvious for them when the criteria should be changed and what advantage it will have. (24887, 21612, 28143) [M3]

[CVS] Synchronizing against an existing project is not well supported

This is somewhat of a CVS problem but relates to the more general issue of when to change the comparison criteria. (21612)

Solution

In the 3.0 M2 release a new Synchronize view will be made available. Not only does the view look different but synchronization workflows have changed, we hope for the better, based on the feedback that we have received over the last two years. Here is a summary of the features of the new sync view:

General features

• The old sync view used to be static, you would synchronize a project(s) and the sync view would display the resources of interest. The new view is dynamic that listens to changes in the workspace and updates the synchronization states of local resources automatically.
• The old sync view would only allow one 'type' of projects to be shown at a time, and switching between them would require a long running operation. For example, if you you were using FTP and CVS you would and only wanted to see your local changes you had to pick the projects and synchronize them seperatly with each provider. Now, both are registered with the sync view and can be toggled quickly.
• Can show the changes in either a table and tree view.
• Instead of embedding the compare views into the sync view, file comparisons are shown in a compare editor. Clean compare editors are re-used so that your editor space is not overloaded and dirty compare editors are left untouched. This switch allows you to have multiple changed compare editors open without being forced to save automatically. This wasn't possible in the old sync view.
• Merges are shown in the sync view. This simplifies the merge actions and allows for merges to be long lived. For example, in CVs wihle working in a branch you can setup to merge the changes in HEAD into your branch. This merge configuration will be saved between sessions and you can easily keep your branch up-to-date with changes in HEAD. When then merge is complete you can Cancel the merge from the views pulldown menu.
• Synchronizations are performed in the background and scheduled refreshes can be configured.
• The changes available in a workspace are shown in the view's title bar. This can help the user be more resources aware and understand if the active filter is filtering out changes.
• There is a Team Synchronizing perspective which helps users who used the sync view as a fast view.

CVS features

• You can perform any of the Team > CVS operations on the elements in the sync view (e.g. create patch, replace with remote, show history)
• Simpler operations in the sync view. You can update/commit in any mode. The prompts will give you more information about what files will be overwritten.
• CVS merges now appear in the sync view and will be persisted between sessions until the merge is cancelled.
• Team > Synchronize with Repository creates a light weight working set and enables for the sync view. This allows selecting a subset of resources to be shown in the sync view.

Issues

• There are two CVS Update/Commit actions in the context menu. Use those at the first level since the onces under Team won't do the right thing. This will be fixed when UI supports actions override for contexts.
• Revision numbers aren't shown in the compare editor.
• Better multiple selection support
• Support for basic navigator actions (e.g. rename, delete...)

Upcomming features

• Have the compare editor display the structure diff in an outline window.
• Key bindings for CVS actions
• Object contribution override will be supported so only one Update/Commit will be shown
• FTP and Dav plugins will be migrated to the new sync view.
• It would be cool to have the comment and user name shown for incoming changes

Where to go from here?

• A prototype has been released with the goal of removing the existing Team > Synchronize actions by the M2 milestone
• Incorporate feedback into new sync view
• Continue to solve the issues listed below
• By M3 have ISVs that where using the internal API over to the new public API