Stephen Butler wrote:
> Quoting Stefan Küng <tortoisesvn_at_gmail.com>:
>
>> Stefan Sperling wrote:
>> [snip]
>
>>> B can now run "svn info" on the tree-conflicted directory to
>>> inquire
>>> about the conflict, and decide what action to take to resolve it,
>>> possibly
>>> discussing the proper fix with A.
>>>
>>> $ svn info /tmp/wcB
>>> Path: /tmp/wcB
>>> URL: file:///tmp/repo
>>> Repository Root: file:///tmp/repo
>>> Repository UUID: eb86d84e-d4f0-407f-a0df-a893da9c5563
>>> Revision: 2
>>> Node Kind: directory
>>> Schedule: normal
>>> Last Changed Author: stsp
>>> Last Changed Rev: 2
>>> Last Changed Date: 2008-01-16 16:31:37 +0100 (Wed, 16 Jan 2008)
>>> Tree conflicts:
>>> The update edited the file 'Foo.c'.
>>> You have deleted 'Foo.c' locally.
>>> Maybe you renamed it?
>>>
>>> Note the last few lines in the output. (Whether this is the right
>>> place to put this information, and whether it has the right format
>>> is still open for debate. See
>>> http://svn.haxx.se/dev/archive-2008-01/0098.shtml)
>>
>> Why does only 'svn info' show the hint? I would prefer if that hint
>> would be shown in the failed commit. After all, that's what the user
>> wanted to do and failed, and showing the user *why* it failed should be
>> done in the commit error message.
>>
>> I guess I could do that in TSVN by calling svn_client_info() after a
>> failed commit, but I think most clients would want that info in the
>> error message, so IMHO it should be done in the svn library.
>
> Hi Stefan,
>
> Our original plan was to write the human-readable descriptions of all the
> tree conflicts in the commit error message.
>
> Unfortunately the svn client's error messages are not allowed to exceed
> 50 characters, and newlines are forbidden, so we had to find another
> place to
> write the text.
>
> 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.
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 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.
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 19:12:43 CET