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.
