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.