Re: current tree-conflicts branch status

On Wed, Jan 16, 2008 at 07:12:14PM +0100, Stefan Küng wrote:
>> The all-too-brief "remains in conflict" error message is currently used in
>> the case of text or property conflicts, so we use it too.
>>
>> That said, we're open to suggestions for a better way to supply the full
>> conflict description to clients.
>
> In that case, I suggest adding some boolean flag when a commit fails and
> has more information available so other clients which don't have the 50
> char limitation can get the 'extended' error message, and of course a
> documented way to get the extended error message.

There is an API that clients can use to get tree conflict descriptions.
So they can present them to the user any time they see fit.

Quoting subversion/include/svn_wc.h on the tree-conflicts branch:

/**
 * Read tree conflict descriptions from @a dir_entry.
 * Append pointers to newly allocated svn_wc_conflict_description_t
 * objects to the array pointed to by @a conflicts.
 * Do all allocations in @a pool.
 *
 * @since New in 1.6.
 */
svn_error_t *
svn_wc_read_tree_conflicts_from_entry(apr_array_header_t *conflicts,
                                      const svn_wc_entry_t *dir_entry,
                                      apr_pool_t *pool);

/**
 * Append to @a descriptions a possibly localized human readable
 * description of a tree conflict described by @a conflict.
 *
 * @since New in 1.6.
 */
svn_error_t *
svn_wc_append_human_readable_tree_conflict_description(
                                       svn_stringbuf_t *descriptions,
                                       svn_wc_conflict_description_t *conflict,
                                       apr_pool_t *pool);

This API is used by the CLI client and should provide all you need
to present tree conflict descriptions in TortoiseSVN.

> I don't think it's a good idea to strip very good features just because the
> command line client (one client among many others) can't handle it.

I am not happy at all either with the current commit error message
of the CLI client. It should at least point the user where to get more
information. This applies to all conflicts.

On the other hand the current style assumes that users have read the book.
This is a good thing, too. It means that users are expected to already know
what a conflict is and how to deal with it when they see the error message.

> I would even suggest to drop the limit of the error messages, and in the
> svn client then simply drop whatever comes after a newline. That way, the
> svn library doesn't have that limitation and only the svn client limits
> itself (and not all other clients too) to 50 chars and no newlines.

I think it would help if clients consistently showed the same or at
least very similar error messages.

-- 
Stefan Sperling <stsp_at_elego.de>                 Software Developer
elego Software Solutions GmbH                            HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12        Tel:  +49 30 23 45 86 96 
13355 Berlin                              Fax:  +49 30 23 45 86 95
http://www.elego.de                 Geschaeftsfuehrer: Olaf Wagner