We need to document how the user should go about resolving tree conflicts, at
least the most common kinds of tree conflict. We need to say how to achieve:
* some reasonable outcome(s) that involve combining elements of both changes
- Solutions will differ depending on the type of tree conflict and on what
state Subversion's tree-conflict implementation will have left the WC in. These
affect whether the user needs to re-schedule a file for add, or just copy it
with operating system commands, for example.
* just the incoming change, throwing away my local change
- In all types of tree conflict, may be as simple as "svn revert" in a WC
being updated, but more complex for committed changes on a target branch being
merged to.
* just my change, throwing away the incoming change
The last two resolutions may be as simple as "svn resolve --accept=..." for all
types of tree conflict.
One particular thing we should address is how to go about resolving a move (or
rename) that resulted in a tree conflict, since it may not be obvious to the
user how to go about finding the "other half" of the rename given that we only
detect one half of it.
Task
Major