C. Michael Pilato wrote:
> 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...
>>> ...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.
> 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
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
(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?)
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-09 08:50:43 CEST