Community
Participate
Working Groups
Coming form Leapfrog, I find the Synchronize View very dangerous. Leapfrog would put conflicts at the top, making you address them separately and immediately, before looking at non-conflicting incoming changes. By default, the synchronize view starts off with incoming changes. The only way to identify conflicts is by a tiny icon which is the same color but has arrowheads at both ends instead of just one. I would rather see conflicts grouped under one TreeItem, and incoming changes under another.
Ok, maybe Leapfrog was more dangerous because it had that Check butotn on the toolbar which accepted everything, not what was selected. But, the icons were cool. Conflict icons were two arrows, one on top of the other, with different colors. Thanks, Randy
Did you try the 'Show only conflicts' toolbar item? That will hide everything except the conflicts. Also, we warn you quite explicitly if you try to blindly get/put conflicts, making sure you won't accidentally overwrite local or remote changes.
Yes, I've tried all Toggles. I think what I want is for the 3rd choice to be selected by default (or remembered). And I would like the option to group conflicts under their own TreeItem (like in LeapFrog). Basically, I hate toolbars and using my mouse, and I don't like having to switch "modes". Currently, I cannot do what I want in any of the four modes. I want to resolve conflicts, and then catch up and then release non-conflicting changes. I can do almost do this in the catchup/release view, but I have to make 3 passes through the tree.
(moved to later)
Reopening
Now that we have the new sync view we should ensure that the filters and the workflows Randy describes are addressed. I too hate using my mouse :)
The new live synchronize view uses filters combined with a table or tree view. Some problems with filters are: - a pain to have to check/uncheck - it's hard to show in the UI which filter would show interesting changes - you would like to force conflicts to be seen (shouldn't be easy to dismiss them) - when a node changes direction (conflict -> outgoing, outgoing -> conflict) it is good to make the new node show in the current view. With filters, this is hard to do. I think it would be good to have an alternate UI presentation in the new live sync view that would use categories in the view instead of direction filters. The change type filters (change, deletion, addition) could remain though. The table view versus tree view would still remain as well but would dictate how the notes below the categories were shown. The UI would look like: + conflicts - file.txt | /ProjectA - this.java | /org.eclipse.this/src + outgoing - file.other | /ProjectA + incoming - build.options | /org.eclipse.this
incoming must come before outgoing. Before releasing code, it is typically necessary to catch up with all incoming changes (including conflicts), before releasing any code. If you just start releasing without catching up, you might put the repository into a non-compiling state and not realize it because you don't have the released code loaded. In MicroEdition, the order was: +conflicts +incoming +outgoing
We won't have a chance to address this for M2.
There are now two new features in the sync view that make it really hard to miss conflicts - and any other changes for that matter. 1. The top part of the view shows the counts for conflicts/incoming/outgoing changes in the current working set and in the entire workspace. 2. Conflict ticks are propagated to parent folders just as compile errors. The overlay is fairly obstrusive so that it's hard to miss them :)
I still consider the leapfrog presentation more usable. For example, when I switch between incoming and outgoing mode, the expansion state of treeitems is not remembered. For example, incoming is: - org.eclipse.draw2d | +-src/org/eclipse/draw2d/internal/graph | +-src/org/eclipse/draw2d/widgets Outoing is: - org.eclipse.draw2d | +-src/org/eclipse/draw2d | +-src/org/eclipse/draw2d/graph | +-src/org/eclipse/draw2d/internal/graph When toggle between incoming/outgoing, all treeitems are collapsed! This includes even the "org.eclipse.draw2d" treeitem which appears in both filters. Obviously it also includes the children of that treeitem because the intersection is empty. But, I would like expansion restored when I go back to the previous filter. The leapfrog approach did not have the problem of remembering expansion because it didn't user filters.
Expansion/selection preservation has been improved - it was too hard to preserve per filter, but pre-filter state is now always restored. In your example, expansion and selection would of been preserved. This also restores when switching layouts. Please open a separate PR for other usability PRs. The original case for this bug was conflicts could easily be missed, but that has been fixed a while ago. We could keep this one open to track 'Randy' comments, but I would prefer if we end this now so that I don't loose track of particular problems. Thanks for the comments though!
Sometimes conflicts are not propogated. I am using 0513 build.
