[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: More user-friendly error messages would be nice

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Mon, 08 Sep 2008 20:42:09 -0400

Vlad Georgescu wrote:
> Karl Fogel wrote:
>> Markus Kuhn <Markus.Kuhn_at_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

C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2008-09-09 02:42:52 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.