[r25803] Interactively dealing with obstructed-addition conflicts

The behavior sounds pretty good to me. A couple questions embedded
below (with the "behavior matrix" code comments)

On Fri, 20 Jul 2007, sussman@tigris.org wrote:
...
> A proposal about how to interactively deal with obstructed-addition conflicts.
> Feedback desired!!
>
> * subversion/svn/conflict-callbacks.c
> (svn_cl__interactive_conflict_handler): handle obstructed-addition conflicts.
...
> --- trunk/subversion/svn/conflict-callbacks.c (original)
> +++ trunk/subversion/svn/conflict-callbacks.c Fri Jul 20 06:49:19 2007
> @@ -143,8 +143,7 @@
> {
> apr_pool_t *subpool = svn_pool_create(pool);
>
> - /* For now, we only handle conflicting file contents. We can deal
> - with other sorts of conflicts someday. */
> + /* Handle conflicting file contents, which is the most common case. */
> if ((desc->node_kind == svn_node_file)
> && (desc->action == svn_wc_conflict_action_edit)
> && (desc->reason == svn_wc_conflict_reason_edited))
> @@ -272,9 +271,71 @@
> }
> }
> }
> - else /* other types of conflicts */
> + /*
> + Dealing with obstruction of additions can be tricky. The
> + obstructing item could be unversioned, versioned, or even
> + schedule-add. Here's a matrix of how the caller should behave,
> + based on results we return.
> +
> + Unversioned Versioned Schedule-Add
> +
> + choose_user skip addition, skip addition skip addition
> + add existing item
> +
> + choose_repos destroy file, schedule-delete, revert add,
> + add new item. add new item. rm file,
> + add new item

I'm really hesitant to flat-out destroy the modified content in the
user's WC (choose_repos option), even upon their request. I can see
why an experienced user might want this behavior, but it's a definite
gotcha for the newbie who selects the wrong option without a full
understanding of the repercussions. Moving it aside into an
unversioned foo.discarded file seems like a safe -- if potentially
annoying -- behavior (possibly overridable in ~/.subversion/config?).

I hadn't realized that it was possible to have a pending schedule of
"delete, then add" on the same path within a WC. I guess this has
been needed to support uncommitted overwrites in a WC?

> +
> + postpone [ bail out ]
> +
> + */
> + else if ((desc->action == svn_wc_conflict_action_add)
> + && (desc->reason == svn_wc_conflict_reason_obstructed))
> {
> - *result = svn_wc_conflict_result_conflicted; /* conflict remains. */
> + const char *answer;
> + const char *prompt;
> +
> + SVN_ERR(svn_cmdline_printf(subpool,
> + _("Conflict discovered when trying to add '%s'.\n"
> + "An object of the same name already exists.\n"),
> + desc->path));
> + prompt = _("Select: (p)ostpone, (m)ine, (t)heirs, (h)elp :");
> +
> + while (1)
> + {
> + svn_pool_clear(subpool);
> +
> + SVN_ERR(svn_cmdline_prompt_user(&answer, prompt, subpool));
> +
> + if ((strcmp(answer, "h") == 0) || (strcmp(answer, "?") == 0))
> + {
> + SVN_ERR(svn_cmdline_printf(subpool,
> + _(" (p)ostpone - resolve the conflict later\n"
> + " (m)ine - accept pre-existing item \n"
> + " (t)heirs - accept incoming item\n"
> + " (h)elp - show this list\n\n")));
> + }
> + if (strcmp(answer, "p") == 0)
> + {
> + *result = svn_wc_conflict_result_conflicted;
> + break;
> + }
> + if (strcmp(answer, "m") == 0)
> + {
> + *result = svn_wc_conflict_result_choose_user;
> + break;
> + }
> + if (strcmp(answer, "t") == 0)
> + {
> + *result = svn_wc_conflict_result_choose_repos;
> + break;
> + }
> + }
> + }
> +
> + else /* other types of conflicts -- do nothing about them. */
> + {
> + *result = svn_wc_conflict_result_conflicted;
> }
...