Re: svn commit: r25670 - in trunk/subversion: include libsvn_subr libsvn_wc svn tests/cmdline/svntest

On 7/7/07, Ben Collins-Sussman <sussman@red-bean.com> wrote:
> On 7/6/07, David Glasser <glasser@mit.edu> wrote:
>
> > I'm really not sure how svn_wc_conflict_result_resolved differs from
> > svn_wc_conflict_result_choose_merged here.
>
> Look at the comment; result_resolved is a 'generic' response which
> means "I resolved the conflict, trust me and move on." I'm
> assuming that it may be used by tree-conflicts someday. The four
> other responses (related to textual merges) are simply very specific
> ways of of saying "the conflict is resolvable; please use *this file*
> to resolve the conflict."

Aha, once I think outside the box of "textual conflicts" this makes
much more sense.

> > > + " (h)elp - show this list\n\n")));
> > > + }
> >
> > * Allow '?' as well as 'h', maybe?
>
> Sure... but as a hidden synonym for 'h'?

Sure, why not? (I doubt we would ever consider using '?' for
something else...)

> > * Do the descriptions for 'mine' and 'theirs' make sense in the 'svn
> > merge' context as well as the update/switch context? I'm not sure.
>
> We already have weird inconsistencies going on there; I think 'svn
> up' produces ".mine, .rX, .rY" fulltexts, and 'svn merge' produces
> ".mine, .left, .right" or something.

I don't just mean the filenames, but the general concept of describing
the versions as being "from the repository" etc. Unfortunately it
doesn't seem like the code paths make it reasonable for the CLI's
callback to use a different message for update and for merge right
now, but it might be something worth considering.

--dave

-- 
David Glasser | glasser_at_mit.edu | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org