| Status and overview of tree-conflicts work. |
| |
| Tree conflict handling spans the following areas: |
| |
| [DETECT] - detect tree conflicts during update/switch/merge |
| [RECORD] - record them in the WC |
| [DISPLAY] - display them (e.g. in "svn status") |
| [COMMIT] - disallow commits while conflicts exist |
| [RESOLVING] - help the user to resolve the conflict |
| [RESOLVED] - enable the user to un-mark the conflict when resolved |
| |
| |
| [DETECT] |
| ======== |
| |
| Purpose: |
| |
| Determine whether each incoming change conflicts with the state of the WC |
| receiving the change. If so, record the fact and ensure that sufficient |
| information is preserved to enable the user to resolve the conflict. Allow |
| the operation to continue on to process other items that are not affected by |
| this conflict. |
| |
| Status: incomplete |
| |
| As far as is currently tested by tree_conflict_tests.py, the status is: |
| |
| Detection of file conflicts: complete |
| Detection of directory conflicts: 2 cases incomplete: |
| - test 8: update add onto add (this is not a primary use case) |
| - test 14: merge del onto changed (this is a primary use case) |
| |
| Primary APIs: |
| |
| For update/switch: |
| svn_delta_editor_t |
| |
| For merge: |
| svn_wc_diff_callbacks3_t |
| |
| Implemented in: |
| |
| For update/switch: |
| subversion/libsvn_wc/update_editor.c |
| (caution: the same code is also used for checkout) |
| |
| For merge: |
| subversion/libsvn_client/merge.c |
| |
| To do: |
| |
| * Fix test 14: merge deletes a changed dir. Needs to compare the dir |
| currently in the target with the dir that was deleted from the merge-left |
| source. If identical, allow the deletion. If not, conflict. |
| |
| * When raising a tree conflict on a dir victim, skip processing everything |
| inside that dir. Check that files don't need similar "skip" handling, or |
| are already getting it. |
| |
| * Check that a dir conflict on the root of an update/switch/merge is handled |
| OK. It need not be handled the same as other dir conflicts, because there |
| is no parent dir available. It just needs to fail in some reasonable way. |
| |
| * Pre-existing obstructions (status "~") or missing items ("!") should be |
| detected first, before attempting to apply the change, and abort the |
| operation. |
| |
| * Unversioned obstructions encountered while applying the change should be |
| handled as a kind of tree conflict. (Given the pre-screening of |
| obstructions to versioned items, this can only occur during add.) |
| |
| Behaviour no longer wanted: |
| |
| Merge: "skipped missing target '...'". As a general principle, I'm wondering |
| if it is no longer acceptable for a merge to skip anything without leaving a |
| persistent record of what it did and why. If the target to be modified by |
| the merge is missing from the target WC in the sense of no longer being |
| under version control, we should instead raise a tree conflict. (If it's |
| missing due to a known and already recorded reason, such as a shallow WC, |
| that might be a bit different.) |
| |
| |
| [RECORD] |
| ======== |
| |
| Purpose: |
| |
| A mechanism for recording, in the WC, what tree conflicts presently exist, |
| and enough information to describe them to the user. |
| |
| Note: This is not the same as recording enough information in the WC to |
| be able to resolve the conflict in any desired way without contacting the |
| repository or source of the merge. For example, for a victim that is a |
| directory, we might need to store or have access to both versions of the |
| whole victim sub-tree. This problem comes under the [RESOLVING] section. |
| |
| Status: complete enough to use. |
| |
| Primary APIs: |
| |
| svn_wc_conflict_description_t |
| |
| /** |
| * Read tree conflict descriptions from @a dir_entry. |
| * Append pointers to newly allocated svn_wc_conflict_description_t |
| * objects to the array pointed to by @a conflicts. |
| * Do all allocations in @a pool. |
| * |
| * @since New in 1.6. |
| */ |
| svn_error_t * |
| svn_wc_read_tree_conflicts_from_entry(apr_array_header_t *conflicts, |
| const svn_wc_entry_t *dir_entry, |
| apr_pool_t *pool); |
| |
| /** |
| * Add a tree conflict to the directory entry belonging to @a adm_access. |
| * Pass a description of the new tree conflict in @a conflict. |
| * Do all allocations in @a pool. |
| * |
| * @since New in 1.6. |
| */ |
| svn_error_t * |
| svn_wc_add_tree_conflict_data(svn_wc_conflict_description_t *conflict, |
| svn_wc_adm_access_t *adm_access, |
| apr_pool_t *pool); |
| |
| To do: |
| |
| Record enough information to be able to reconstruct the "old", "mine" and |
| "theirs" versions of the item, and possibly also a complete local copy of |
| them. |
| |
| Notes: |
| |
| Special case: The root of the WC is the victim of a tree conflict. (This can |
| only happen with a merge, as there can be no tree change scheduled locally |
| for an update to conflict with.) |
| Problem: There is no parent directory in which to store the conflict info. |
| Solution: Abort with an error, and don't change the WC. |
| |
| |
| [DISPLAY] |
| ========= |
| |
| Status: complete enough to use, but wants improvement. |
| |
| "svn info" |
| mechanism complete but ugly |
| |
| "svn status" |
| mechanism complete |
| |
| "svn up/sw/merge" (progress notifications) |
| mechanism complete |
| |
| Primary APIs: |
| |
| "svn info" |
| |
| "svn status" |
| |
| "svn up/sw/merge" (progress notifications) |
| |
| To do: |
| |
| * Design: conceptually, do we want to see conflicts on the parent directory |
| or on the victims? Due to what falls out of the early implementation, we |
| were heading for a concept of resolving the parent directory... but I |
| don't feel that's right. See also [RESOLVED]. |
| |
| * Clean up the "svn info" text: make it much less verbose. |
| |
| * Consider whether "svn st ITEM" should show conflict on victim ITEM. |
| |
| Notes: |
| |
| * Making the information available to be displayed is part of [DETECT]. |
| |
| |
| [COMMIT] |
| ======== |
| |
| Status: incomplete |
| |
| When parent and victim are included: complete? |
| When only the parent is included: complete? |
| When only the victim is included: incomplete |
| |
| Purpose: |
| |
| Disallow commits while conflicts exist in the items proposed for commit. |
| |
| When directory D has a tree conflict on one or more children, what does |
| that mean for |
| (a) a child that is a victim? |
| (b) a child that is not a victim? |
| (c) the directory D, when treated as non-recursively (depth 0)? |
| Answer: |
| (a) Each victim is in conflict and cannot be committed, even if the |
| "conflict" status information is stored in the parent D. |
| (b) Each non-victim child is fine and can be committed independently |
| of its parent. |
| (c) NOT SURE... Could work either way. |
| |
| To do: |
| |
| * Make commits fail when tree conflicts exist, even when the victim's parent |
| is not part of the requested commit. |
| |
| |
| [RESOLVING] |
| =========== |
| |
| Purpose: |
| |
| 1. Provide metadata about what happened. |
| - See [DISPLAY]. |
| |
| 2. Provide access to all data involved in the conflict. |
| - Incomplete. |
| |
| 3. Enable the user to resolve the conflict by creating a desired working |
| version (including the desired scheduling). |
| - Is possible. No assistance is provided. Needs evaluation. |
| - Not sure what's needed here. |
| |
| 4. Enable the user to mark the conflict as resolved. |
| - Incomplete. |
| |
| Design: |
| |
| * Keep all of the merge-left + merge-right + working data locally. (Ideally, |
| by analogy with text conflicts. May not be necessary for a first pass.) |
| * Ensure user has suitable and obvious commands for resolving. |
| - may include merge, delete, copy, etc. |
| - may require hints or documentation on what commands should be used. |
| * Interactive resolution should recognise tree conflicts and provide |
| basic and common resolutions. |
| * Ability to use "svn resolved" to say "the conflict on victim V is |
| resolved". |
| * Ability to use "svn resolve --accept=..." to say "resolve the conflict on |
| victim V by choosing ...". |
| |
| Status: incomplete |
| |
| * Mark as resolved, by command: the basic "svn resolved PARENT" works to some |
| extent, but needs attention. |
| Issue #3145 <https://issues.apache.org/jira/browse/SVN-3145> |
| |
| * Mark as resolved, interactively: not started. |
| Issue #3144 <https://issues.apache.org/jira/browse/SVN-3144> |
| |
| To do: |
| |
| * Design: conceptually, do we want to "resolve" the parent directory or |
| the victims? Due to what falls out of the early implementation, we were |
| heading for a concept of resolving the parent directory... but I don't |
| feel that's right. See also [DISPLAY]. |
| |
| * Ensure the basic "resolved"/"resolve --accept=" works on a whole directory. |
| |
| * Allow individual victims to be marked as "resolved". |
| |