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

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."

> > + " (h)elp - show this list\n\n")));
> > + }
>
> * Allow '?' as well as 'h', maybe?

Sure... but as a hidden synonym for 'h'?

>
> * At the risk of bikeshedding, (r)esolved instead of (a)ccept for
> consistency with 'svn resolved'

Yeah, I think this is a good idea, as discussed in IRC.

>
> * 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.

> You've got to watch out here: there are three random tests that call
> create_config_dir with a config_contents file of their own, so this'll
> get lost there (hopefully it's irrelevant). Perhaps we should just
> append the default text to the provided one (I believe it's fine to
> have duplicate sections in our format). (The same should probably be
> done for the servers file, although no test actually customizes that.)
>

Gah! Yeah, let's fix this.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jul 8 04:36:15 2007