1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
|
======================================================================
EXAMPLE TEAM UI API USAGES
======================================================================
1. embeding sync viewer in dialog/wizard
2. added a new content provider (logical views of sync info changes)
3. adding custom label decorations
4. actions/menus
5. fetching sync info set without instantiating a participant
6. fetch and wait for the event collector to finish processing the changes
7. showing in a diff viewer either a static model (doesn't update when changes occur) or dynamic
======================================================================
PR LIST (07-01-2004)
======================================================================
x P3 schedule support by participant.
this requires changing the refresh jobs to accept scheduling different jobs. Essentially being able to have an
ordered *queue of refreshes. Also, participant will need a schedule object to encapsulate the schedule logic.
x P3 status message could be more precise instead of simply "Working". But to do this we need access to the job progress monitor
and it isn't available API from the UI. (removed status in sync view, progress will be shown in the progress shell).
x P1 end of refresh prompt should be a property change notice, and let the participant decide what to do!
x P2 decide overview page contents and how it should be used
x remove duplicated tree/table viewers classes. the orignial ones simply have the INavigable behavior.
x P1 make changes section only be a pagebook. this would easily allow adding any number of composites to the page?
should look at memory consuption and ensure that we are disposing properly!
- compareeditorinput fetcheds remote content outside of a progress monitor
x decorations for SyncInfoDiffElements (of which type.. project persistent property setting?)
x labels for compare editors (text merge viewers and title for diff viewer)
x generic navigate support for SyncInfoDiffTreeViewer, PRd compare for API support
x readonly state for compare panes
- progress support added when fetching (e.g. caching contents in ITypedElement). This will require compare to add some API.
x INavigable in compare needs to be made API.
- details dialog needs to create composites once then display them. Or only create once!!!!
x sync set filtering creation must be more precise. For example you should be able to specify a root and a direction.
x cvs update/commit action in sync view toolbar are not updating their state anymore :(
x P3 mode switching at the end of a refresh to ensure that changes are shown if available
x P2 need an event for adding roots to a subscriber to update the list shown
x memory and sync set disposal in syncsetcompare input!!!! VERY IMPORTANT!!!
- overiding outgoing/incoming doesn't show the changes in the commit dialog because the filter is only configured to show in one direction.
======================================================================
PR LIST (16-01-2004)
======================================================================
- progress monitoring in SyncSet.reset and such. there are many places where null progress monitors are passed along.
- showing sync view in commit dialog is complicated because there is no easy way of finding out exactly which resources will be committed at the
point the commit comment dialog is shown. Need to provide new API on the commit dialog for this.
- convert details dialogs that show sync view into wizards, this allows more room to browse the changes. almost like the refactoring. Preview >> button instead of Next >>.
- job status handler API or not??
======================================================================
PR LIST (26-01-2004)
======================================================================
- navigable APIs must be consolidated, sync view navigation
- compare configuration review
- logical view extensions
- based on project natures
- ui (e.g. layouts/context menu??)
- content provider should not assume diff nodes have associated resources
- content provider input? Is it a diff node or sync set? diff node hack required for getting the
compare editor input working.
- viewer input as a diffnode with a sync set seems wrong?
- share reconciling with existing (e.g. using compare contents to resolve)
- comment grouping logical view
- target migration
======================================================================
PR LIST (30-01-2004) MV
======================================================================
- actions in sync view all assume that selection will have a resource (e.g refresh action).
- how would a refresh know what to select if a change comment node was selected, for example
- could first attempt to obtain resource and, if that fails, visit children to obtain resources
[jm] I think that actions will have to know about DiffNodes and we need the helper to
get the list of children nodes.
- sorter is related to input so may need to change when input does
- there does not appear to be a clean way to change the sorter and input without causing two refreshes
- SyncInfoSet##getOutOfSyncDescendants(IResource) is speced to include the resource itself if it is out-of-sync
- this is a bit confusing as the name implies otherwise
- should either consider a name change or a soec change
[jm] I never understood why is was spec'd like that :) You can decide...
- compare input requires root node to have children or diff viewer is not added
- this is problematic when creating a wizard page that is dynamically populated
- not sure if there's problems caused by returning true when there are no children
[jm] I think this it's fine to have root nodes return true to hasChildren. I don't like
compares subtle way of determining is the diff viewer should be shown, but in our case a
root node can safely always have children.
- several places require a resource
- e.g. conflict propogation requires a resource but shouldn't (modified to work without a resource)
x conflicts do not propogate in comment view [jm] fixed
[jm] we have to change this assumption everywhere! Actions, label decorators... and such.
- there are times when the sync set changes but the input hasn't yet and the given input
doesn't handle outgoing changes. For example, when changing from incoming to outgoing with
the change log root, the change log root gets a reset from the sync set then the input
is changed. this can cause an NPE. Must look into the ordering here.
- the test cases starve the subscriber event handler such that an event has additions and removals for the same resources
- this causes failures in the diff tree builders
- although less likely in UI, can still happen
- need tests for these scenarios to ensure generated event is correct after addition and removal
- there are several places in SyncInfoSet and in the DiffNodes where we must use the workspace root
as the input resource to imply get all members? Maybe this should be cleaned up a bit.
- SyncInfoSet must be cleaned up a lot, the API is vague and method names are not clear.
- SyncInfoDiffNode doesn't have to return a resource or a syncinfo. By definition a diff node already has API
for returning a sync kind getKind() and access to all three resources getRight(), getLeft(), getAncestor().
|
