You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Markus Kuhn <Ma...@cl.cam.ac.uk> on 2008/09/08 17:13:05 UTC
More user-friendly error messages would be nice
Feature suggestion: more user-friendly error messages
Having introduced Subversion 1.4 as the means to edit departmental web
pages, I find that even quite computer-literate users (professors of
computer science, etc.) regularly stumble over Subversion's sometimes
rather inpenetrable style of reporting error conditions.
Example of a less than ideally presented one:
Sending index-b.html
Transmitting file data .svn: Commit failed (details follow):
svn: Out of date: '/trunk/html/teaching/projects/index.html' in
transaction '1241-1'
svn: Your commit message was left in a temporary file:
svn: '/homes/someuser/projects-pages/svn-commit.3.tmp'
Problems:
- no explanation of what "out of date" means; a full sentence would be since
- no guidance towards how to resolve the situation ("svn update")
- less important technical details (e.g. "transaction '1241-1'",
the full path of the commit message) are displayed equally
prominent as the actual problem
- confusing punctuation ("file data .svn: Commit")
- use of absolute rather than relative pathnames
- (speculation:) the structure of the error message seems to be motivated
by convenience for the developer rather than the user's convenience
A nicer way of presenting the same message might be:
Your attempt to commit your changes in the file 'index-b.html' back to
the repository has failed. (Transaction 1241-1)
Reason: You modified an out-of-date version of the file, obtained with
an update at 2008-09-03 12:05, but since then user mgk25 has also
committed changes (at 2008-09-03 16:06).
How to resolve: Before you can commit your changes, first update
your working copy by merging in those other changes with "svn update".
(Your commit message was left in a temporary file: 'svn-commit.3.tmp'.)
Concurrent editing and resolving edit conflicts can be complicated stuff
for occasional users of Subversion. Error messages that clearly explain
in plain English what went wrong and what will fix it might help to
make Subversion accessible to a much wider user base than just
experienced programmers.
Markus
--
Markus Kuhn, Computer Laboratory, University of Cambridge
http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: More user-friendly error messages would be nice
Posted by Vlad Georgescu <vg...@gmail.com>.
C. Michael Pilato wrote:
> Vlad Georgescu wrote:
>> Karl Fogel wrote:
>>> Markus Kuhn <Ma...@cl.cam.ac.uk> writes:
>>>> Feature suggestion: more user-friendly error messages
>>> Oh, we are definitely on board with that already...
>>>
>>> http://subversion.tigris.org/issues/show_bug.cgi?id=1254
>>>
>>> ...which, as you can see from its last comment, split into individual
>>> issues for specific error messages. Not that we need an issue for every
>>> message; we just clean them up when we can.
>>>
>>> Your suggested solution for this particular error would take some work
>>> (since the client currently doesn't know the "other" user who committed
>>> in the meantime).
>> The out of dateness error is generated on the server side, so it shouldn't be
>> too hard to include the extra information. We should also have different error
>> messages for each type of out of dateness. Something like:
>>
>> User 'bar' has also changed file 'foo' in revision 4.
>> File 'foo' was already deleted by user 'bar' in revision 4.
>> File 'foo' was already added by user 'bar' in revision 4.
>> etc.
>
> We just need to be careful here, authz-wise, with what we return. You
> mustn't assume that a given authz system provides those who can write to a
> path necessarily with the right to also read it or its history. That means
> we can't generate such errors down in the FS layer because the Repos layer
> might then have filter the error out, potentially losing valuable
> non-privileged information in the process. Baby. Bath water. You get the
> picture.
>
Oh, when I wrote that, I was thinking only of the errors we generate in
libsvn_repos, in the commit editor. You're right about the need to be careful
about authz.
(Interestingly, open_file() in libsvn_repos/commit.c always checks for read
access, so it appears that you can't write to a file if you don't also have read
access. Is this intended behavior?)
--
Vlad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: More user-friendly error messages would be nice
Posted by "C. Michael Pilato" <cm...@collab.net>.
Vlad Georgescu wrote:
> Karl Fogel wrote:
>> Markus Kuhn <Ma...@cl.cam.ac.uk> writes:
>>> Feature suggestion: more user-friendly error messages
>> Oh, we are definitely on board with that already...
>>
>> http://subversion.tigris.org/issues/show_bug.cgi?id=1254
>>
>> ...which, as you can see from its last comment, split into individual
>> issues for specific error messages. Not that we need an issue for every
>> message; we just clean them up when we can.
>>
>> Your suggested solution for this particular error would take some work
>> (since the client currently doesn't know the "other" user who committed
>> in the meantime).
>
> The out of dateness error is generated on the server side, so it shouldn't be
> too hard to include the extra information. We should also have different error
> messages for each type of out of dateness. Something like:
>
> User 'bar' has also changed file 'foo' in revision 4.
> File 'foo' was already deleted by user 'bar' in revision 4.
> File 'foo' was already added by user 'bar' in revision 4.
> etc.
We just need to be careful here, authz-wise, with what we return. You
mustn't assume that a given authz system provides those who can write to a
path necessarily with the right to also read it or its history. That means
we can't generate such errors down in the FS layer because the Repos layer
might then have filter the error out, potentially losing valuable
non-privileged information in the process. Baby. Bath water. You get the
picture.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: More user-friendly error messages would be nice
Posted by Vlad Georgescu <vg...@gmail.com>.
Karl Fogel wrote:
> Markus Kuhn <Ma...@cl.cam.ac.uk> writes:
>> Feature suggestion: more user-friendly error messages
>
> Oh, we are definitely on board with that already...
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=1254
>
> ...which, as you can see from its last comment, split into individual
> issues for specific error messages. Not that we need an issue for every
> message; we just clean them up when we can.
>
> Your suggested solution for this particular error would take some work
> (since the client currently doesn't know the "other" user who committed
> in the meantime).
The out of dateness error is generated on the server side, so it shouldn't be
too hard to include the extra information. We should also have different error
messages for each type of out of dateness. Something like:
User 'bar' has also changed file 'foo' in revision 4.
File 'foo' was already deleted by user 'bar' in revision 4.
File 'foo' was already added by user 'bar' in revision 4.
etc.
I don't have time to take a look at this now, but I think it's low hanging fruit.
--
Vlad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: More user-friendly error messages would be nice
Posted by Karl Fogel <kf...@red-bean.com>.
Markus Kuhn <Ma...@cl.cam.ac.uk> writes:
> Feature suggestion: more user-friendly error messages
Oh, we are definitely on board with that already...
http://subversion.tigris.org/issues/show_bug.cgi?id=1254
...which, as you can see from its last comment, split into individual
issues for specific error messages. Not that we need an issue for every
message; we just clean them up when we can.
Your suggested solution for this particular error would take some work
(since the client currently doesn't know the "other" user who committed
in the meantime). Nonetheless, the error could still be greatly
improved. Only time constraints prevent this, nothing more. If you
have time to submit a patch, it would be most welcome (note that the
regression test suite may need updating too). Otherwise, somebody will
get to this when they can.
(Experience suggests that no matter what text we throw in front of the
user for an out-of-date error, many users will not read it and will not
understand what happened. Making the text more verbose just frightens
them more. I'm not saying the error can't be improved, merely pointing
out that it will make no difference for many people. We do not have a
unified audience, that's part of the problem.)
-Karl
> Having introduced Subversion 1.4 as the means to edit departmental web
> pages, I find that even quite computer-literate users (professors of
> computer science, etc.) regularly stumble over Subversion's sometimes
> rather inpenetrable style of reporting error conditions.
>
> Example of a less than ideally presented one:
>
> Sending index-b.html
> Transmitting file data .svn: Commit failed (details follow):
> svn: Out of date: '/trunk/html/teaching/projects/index.html' in
> transaction '1241-1'
> svn: Your commit message was left in a temporary file:
> svn: '/homes/someuser/projects-pages/svn-commit.3.tmp'
>
> Problems:
>
> - no explanation of what "out of date" means; a full sentence would be since
>
> - no guidance towards how to resolve the situation ("svn update")
>
> - less important technical details (e.g. "transaction '1241-1'",
> the full path of the commit message) are displayed equally
> prominent as the actual problem
>
> - confusing punctuation ("file data .svn: Commit")
>
> - use of absolute rather than relative pathnames
>
> - (speculation:) the structure of the error message seems to be motivated
> by convenience for the developer rather than the user's convenience
>
> A nicer way of presenting the same message might be:
>
> Your attempt to commit your changes in the file 'index-b.html' back to
> the repository has failed. (Transaction 1241-1)
>
> Reason: You modified an out-of-date version of the file, obtained with
> an update at 2008-09-03 12:05, but since then user mgk25 has also
> committed changes (at 2008-09-03 16:06).
>
> How to resolve: Before you can commit your changes, first update
> your working copy by merging in those other changes with "svn update".
>
> (Your commit message was left in a temporary file: 'svn-commit.3.tmp'.)
>
> Concurrent editing and resolving edit conflicts can be complicated stuff
> for occasional users of Subversion. Error messages that clearly explain
> in plain English what went wrong and what will fix it might help to
> make Subversion accessible to a much wider user base than just
> experienced programmers.
>
> Markus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org