I'm glad we found out a common point of view. A better error message,
that indicates the cause (at least, in the provided example, it should
be very clear what is triggering the error), would definitely help save
some time, since no other command works to obtain other information
about this working copy "blockage".
Indeed, I work on Windows.
Should I create a new issue regarding the error messages for this
situation, or someone else does this?!
On 19.02.2014 16:42, Stefan Sperling wrote:
> On Wed, Feb 19, 2014 at 02:52:48PM +0200, Florin Avram wrote:
>> I understand your point, but I have the feeling somewhere there is not a
>> correct decision and things can be improved.
>>
>> What I'm trying to say is that what Subversion does in this case is not too
>> obvious. Think to the following situation:
>> - wc_root_dir
>> -- dir1/file.txt
>> -- dir2/file.txt
>> When the client states "The parameter is incorrect", this is useless
>> information for a common user (it could be some library internal error?!).
> I agree here. The error messages that result from this problem are
> definitely not user friendly.
>
> This is not a new problem. Subversion has always had problems with
> many of its error messages being far from understandable for users :(
> I actually gave a conference talk on this very subject once, slides at
> http://www.elegosoft.com/files/Downloads/Subversion_Day_2011/svn-day-berlin-2011_sperling_subversion-error-messages-demystified.pdf
>
> In your case, "The parameter is incorrect" is most likely coming from
> the Windows operating system. I'm seeing "is not a directory" instead.
>
>> I agree with Philip Martin - before doing any changes to the working copy
>> (and block it, from my point of view, after the example situation) it should
>> do some checks and warn the user that the operation is not possible. This
>> allows to work with the working copy further (runt other commands) and fix
>> the issue.
> Sometimes, it's hard to do such checks upfront, because we often
> don't know what problems can happen until they actually occur.
> Some operations can have way too many side effects to consider upfront,
> and checking upfront could hurt performance a lot in many cases.
> And if we're not very careful, such checks might actually end up breaking
> legitimate use cases that were overlooked when the checks were implemented.
>
> I think a better approach would be to try to systematically improve all
> error messages raised by the work queue subsystem in the working copy
> library, adding hints to the likely cause of the problem. I'd fully
> support a new entry in our issue tracker for such a task. Most of these
> messages are beyond what a normal user should have to deal with.
>
Received on 2014-02-19 16:09:44 CET