1 | Status and overview of tree-conflicts work. |
---|
2 | |
---|
3 | Tree conflict handling spans the following areas: |
---|
4 | |
---|
5 | [DETECT] - detect tree conflicts during update/switch/merge |
---|
6 | [RECORD] - record them in the WC |
---|
7 | [DISPLAY] - display them (e.g. in "svn status") |
---|
8 | [COMMIT] - disallow commits while conflicts exist |
---|
9 | [RESOLVING] - help the user to resolve the conflict |
---|
10 | [RESOLVED] - enable the user to un-mark the conflict when resolved |
---|
11 | |
---|
12 | |
---|
13 | [DETECT] |
---|
14 | ======== |
---|
15 | |
---|
16 | Purpose: |
---|
17 | |
---|
18 | Determine whether each incoming change conflicts with the state of the WC |
---|
19 | receiving the change. If so, record the fact and ensure that sufficient |
---|
20 | information is preserved to enable the user to resolve the conflict. Allow |
---|
21 | the operation to continue on to process other items that are not affected by |
---|
22 | this conflict. |
---|
23 | |
---|
24 | Status: incomplete |
---|
25 | |
---|
26 | As far as is currently tested by tree_conflict_tests.py, the status is: |
---|
27 | |
---|
28 | Detection of file conflicts: complete |
---|
29 | Detection of directory conflicts: 2 cases incomplete: |
---|
30 | - test 8: update add onto add (this is not a primary use case) |
---|
31 | - test 14: merge del onto changed (this is a primary use case) |
---|
32 | |
---|
33 | Primary APIs: |
---|
34 | |
---|
35 | For update/switch: |
---|
36 | svn_delta_editor_t |
---|
37 | |
---|
38 | For merge: |
---|
39 | svn_wc_diff_callbacks3_t |
---|
40 | |
---|
41 | Implemented in: |
---|
42 | |
---|
43 | For update/switch: |
---|
44 | subversion/libsvn_wc/update_editor.c |
---|
45 | (caution: the same code is also used for checkout) |
---|
46 | |
---|
47 | For merge: |
---|
48 | subversion/libsvn_client/merge.c |
---|
49 | |
---|
50 | To do: |
---|
51 | |
---|
52 | * Fix test 14: merge deletes a changed dir. Needs to compare the dir |
---|
53 | currently in the target with the dir that was deleted from the merge-left |
---|
54 | source. If identical, allow the deletion. If not, conflict. |
---|
55 | |
---|
56 | * When raising a tree conflict on a dir victim, skip processing everything |
---|
57 | inside that dir. Check that files don't need similar "skip" handling, or |
---|
58 | are already getting it. |
---|
59 | |
---|
60 | * Check that a dir conflict on the root of an update/switch/merge is handled |
---|
61 | OK. It need not be handled the same as other dir conflicts, because there |
---|
62 | is no parent dir available. It just needs to fail in some reasonable way. |
---|
63 | |
---|
64 | * Pre-existing obstructions (status "~") or missing items ("!") should be |
---|
65 | detected first, before attempting to apply the change, and abort the |
---|
66 | operation. |
---|
67 | |
---|
68 | * Unversioned obstructions encountered while applying the change should be |
---|
69 | handled as a kind of tree conflict. (Given the pre-screening of |
---|
70 | obstructions to versioned items, this can only occur during add.) |
---|
71 | |
---|
72 | Behaviour no longer wanted: |
---|
73 | |
---|
74 | Merge: "skipped missing target '...'". As a general principle, I'm wondering |
---|
75 | if it is no longer acceptable for a merge to skip anything without leaving a |
---|
76 | persistent record of what it did and why. If the target to be modified by |
---|
77 | the merge is missing from the target WC in the sense of no longer being |
---|
78 | under version control, we should instead raise a tree conflict. (If it's |
---|
79 | missing due to a known and already recorded reason, such as a shallow WC, |
---|
80 | that might be a bit different.) |
---|
81 | |
---|
82 | |
---|
83 | [RECORD] |
---|
84 | ======== |
---|
85 | |
---|
86 | Purpose: |
---|
87 | |
---|
88 | A mechanism for recording, in the WC, what tree conflicts presently exist, |
---|
89 | and enough information to describe them to the user. |
---|
90 | |
---|
91 | Note: This is not the same as recording enough information in the WC to |
---|
92 | be able to resolve the conflict in any desired way without contacting the |
---|
93 | repository or source of the merge. For example, for a victim that is a |
---|
94 | directory, we might need to store or have access to both versions of the |
---|
95 | whole victim sub-tree. This problem comes under the [RESOLVING] section. |
---|
96 | |
---|
97 | Status: complete enough to use. |
---|
98 | |
---|
99 | Primary APIs: |
---|
100 | |
---|
101 | svn_wc_conflict_description_t |
---|
102 | |
---|
103 | /** |
---|
104 | * Read tree conflict descriptions from @a dir_entry. |
---|
105 | * Append pointers to newly allocated svn_wc_conflict_description_t |
---|
106 | * objects to the array pointed to by @a conflicts. |
---|
107 | * Do all allocations in @a pool. |
---|
108 | * |
---|
109 | * @since New in 1.6. |
---|
110 | */ |
---|
111 | svn_error_t * |
---|
112 | svn_wc_read_tree_conflicts_from_entry(apr_array_header_t *conflicts, |
---|
113 | const svn_wc_entry_t *dir_entry, |
---|
114 | apr_pool_t *pool); |
---|
115 | |
---|
116 | /** |
---|
117 | * Add a tree conflict to the directory entry belonging to @a adm_access. |
---|
118 | * Pass a description of the new tree conflict in @a conflict. |
---|
119 | * Do all allocations in @a pool. |
---|
120 | * |
---|
121 | * @since New in 1.6. |
---|
122 | */ |
---|
123 | svn_error_t * |
---|
124 | svn_wc_add_tree_conflict_data(svn_wc_conflict_description_t *conflict, |
---|
125 | svn_wc_adm_access_t *adm_access, |
---|
126 | apr_pool_t *pool); |
---|
127 | |
---|
128 | To do: |
---|
129 | |
---|
130 | Record enough information to be able to reconstruct the "old", "mine" and |
---|
131 | "theirs" versions of the item, and possibly also a complete local copy of |
---|
132 | them. |
---|
133 | |
---|
134 | Notes: |
---|
135 | |
---|
136 | Special case: The root of the WC is the victim of a tree conflict. (This can |
---|
137 | only happen with a merge, as there can be no tree change scheduled locally |
---|
138 | for an update to conflict with.) |
---|
139 | Problem: There is no parent directory in which to store the conflict info. |
---|
140 | Solution: Abort with an error, and don't change the WC. |
---|
141 | |
---|
142 | |
---|
143 | [DISPLAY] |
---|
144 | ========= |
---|
145 | |
---|
146 | Status: complete enough to use, but wants improvement. |
---|
147 | |
---|
148 | "svn info" |
---|
149 | mechanism complete but ugly |
---|
150 | |
---|
151 | "svn status" |
---|
152 | mechanism complete |
---|
153 | |
---|
154 | "svn up/sw/merge" (progress notifications) |
---|
155 | mechanism complete |
---|
156 | |
---|
157 | Primary APIs: |
---|
158 | |
---|
159 | "svn info" |
---|
160 | |
---|
161 | "svn status" |
---|
162 | |
---|
163 | "svn up/sw/merge" (progress notifications) |
---|
164 | |
---|
165 | To do: |
---|
166 | |
---|
167 | * Design: conceptually, do we want to see conflicts on the parent directory |
---|
168 | or on the victims? Due to what falls out of the early implementation, we |
---|
169 | were heading for a concept of resolving the parent directory... but I |
---|
170 | don't feel that's right. See also [RESOLVED]. |
---|
171 | |
---|
172 | * Clean up the "svn info" text: make it much less verbose. |
---|
173 | |
---|
174 | * Consider whether "svn st ITEM" should show conflict on victim ITEM. |
---|
175 | |
---|
176 | Notes: |
---|
177 | |
---|
178 | * Making the information available to be displayed is part of [DETECT]. |
---|
179 | |
---|
180 | |
---|
181 | [COMMIT] |
---|
182 | ======== |
---|
183 | |
---|
184 | Status: incomplete |
---|
185 | |
---|
186 | When parent and victim are included: complete? |
---|
187 | When only the parent is included: complete? |
---|
188 | When only the victim is included: incomplete |
---|
189 | |
---|
190 | Purpose: |
---|
191 | |
---|
192 | Disallow commits while conflicts exist in the items proposed for commit. |
---|
193 | |
---|
194 | When directory D has a tree conflict on one or more children, what does |
---|
195 | that mean for |
---|
196 | (a) a child that is a victim? |
---|
197 | (b) a child that is not a victim? |
---|
198 | (c) the directory D, when treated as non-recursively (depth 0)? |
---|
199 | Answer: |
---|
200 | (a) Each victim is in conflict and cannot be committed, even if the |
---|
201 | "conflict" status information is stored in the parent D. |
---|
202 | (b) Each non-victim child is fine and can be committed independently |
---|
203 | of its parent. |
---|
204 | (c) NOT SURE... Could work either way. |
---|
205 | |
---|
206 | To do: |
---|
207 | |
---|
208 | * Make commits fail when tree conflicts exist, even when the victim's parent |
---|
209 | is not part of the requested commit. |
---|
210 | |
---|
211 | |
---|
212 | [RESOLVING] |
---|
213 | =========== |
---|
214 | |
---|
215 | Purpose: |
---|
216 | |
---|
217 | 1. Provide metadata about what happened. |
---|
218 | - See [DISPLAY]. |
---|
219 | |
---|
220 | 2. Provide access to all data involved in the conflict. |
---|
221 | - Incomplete. |
---|
222 | |
---|
223 | 3. Enable the user to resolve the conflict by creating a desired working |
---|
224 | version (including the desired scheduling). |
---|
225 | - Is possible. No assistance is provided. Needs evaluation. |
---|
226 | - Not sure what's needed here. |
---|
227 | |
---|
228 | 4. Enable the user to mark the conflict as resolved. |
---|
229 | - Incomplete. |
---|
230 | |
---|
231 | Design: |
---|
232 | |
---|
233 | * Keep all of the merge-left + merge-right + working data locally. (Ideally, |
---|
234 | by analogy with text conflicts. May not be necessary for a first pass.) |
---|
235 | * Ensure user has suitable and obvious commands for resolving. |
---|
236 | - may include merge, delete, copy, etc. |
---|
237 | - may require hints or documentation on what commands should be used. |
---|
238 | * Interactive resolution should recognise tree conflicts and provide |
---|
239 | basic and common resolutions. |
---|
240 | * Ability to use "svn resolved" to say "the conflict on victim V is |
---|
241 | resolved". |
---|
242 | * Ability to use "svn resolve --accept=..." to say "resolve the conflict on |
---|
243 | victim V by choosing ...". |
---|
244 | |
---|
245 | Status: incomplete |
---|
246 | |
---|
247 | * Mark as resolved, by command: the basic "svn resolved PARENT" works to some |
---|
248 | extent, but needs attention. |
---|
249 | Issue #3145 <http://subversion.tigris.org/issues/show_bug.cgi?id=3145> |
---|
250 | |
---|
251 | * Mark as resolved, interactively: not started. |
---|
252 | Issue #3144 <http://subversion.tigris.org/issues/show_bug.cgi?id=3144> |
---|
253 | |
---|
254 | To do: |
---|
255 | |
---|
256 | * Design: conceptually, do we want to "resolve" the parent directory or |
---|
257 | the victims? Due to what falls out of the early implementation, we were |
---|
258 | heading for a concept of resolving the parent directory... but I don't |
---|
259 | feel that's right. See also [DISPLAY]. |
---|
260 | |
---|
261 | * Ensure the basic "resolved"/"resolve --accept=" works on a whole directory. |
---|
262 | |
---|
263 | * Allow individual victims to be marked as "resolved". |
---|
264 | |
---|