Stefan Sperling wrote:
> 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.
Looks ok.
But how about a function that appends that description to an svn_error_t
object? I could then use that function to append the 'human readable
tree conflict description' to the commit error object before I show it
to the user.
And of course, there has to be an easy way to know from a failed commit
(from the error object) that I should use those API's to get more
information about the failed commit.
>> 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.
One think I don't quite understand: why is there such a limit in the svn
client? Is this documented somewhere?
The reason I'm asking: pre-commit hook scripts can return an error
string too which is then shown in the client. And I have seen such
scripts which return strings that are much longer than 50 chars and even
contain newlines. At least with TSVN, those are shown correctly (haven't
tested with the svn client though).
> On the other hand the current style assumes that users have read the book.
But that's a wrong assumption. I can guarantee you that most users don't
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.
You're expecting way too much from your users.
For example, I know what a conflict is - after all I'm using Subversion
(TSVN) since the early days. But when I saw your examples on how tree
conflicts are now handled, I was a little bit confused about what to do
to resolve that conflict. Only when I saw the output from 'svn info' in
your example I knew what to do. But without that, I had no idea - it
wasn't the file itself that was in conflict but the tree.
Now think about other users. They upgrade their svn client to the new
version, and one day they get a conflict. They try to resolve the
conflict as they did before (maybe they've even read the book before,
but not the new version which explains tree conflicts), but that doesn't
work. They try some more, start fiddling around the working copy, maybe
even inside the .svn folders (yes, users do that first, *then* ask on
the mailing list or read the docs) - and we have to deal with the mess.
>> 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.
Well, yes, that would be good. But limit all clients just because one
client can't handle long messages and/or newlines?
All I'm asking for is that you should not put the limit in the library
but only where it applies: in the svn command line client.
My guess is that this limit comes from some console limitations. But all
other svn clients are not for the console and therefore don't have such
a limit. Let those clients have the much better error messages which
explain things better, and let the command line client deal with its own
limit.
If you need some analogy: if you write an image viewer for old computers
with only 8MB RAM, would you still keep that limit even if your app
would run on a modern computer? Would you reject showing an image which
requires 20MB RAM to show even though the modern PC has 1GB of free
memory available? Of course not! You would apply the limit only where it
occurs, not everywhere.
Another thing to remember: even the svn command line client sometimes
appends its own help text to error messages (e.g., 'run the cleanup
command' after a command failed due to a locked wc).
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-01-16 22:10:48 CET