[MERGE] Give nicer errors for some write operations on read-only transports.

[Robert Collins]

On Mon, 2007-09-03 at 22:54 +0100, James Westby wrote:
> On (04/09/07 07:44), Robert Collins wrote:
> > On Mon, 2007-09-03 at 22:39 +0100, James Westby wrote:
> > > As I understand it your aversion to "look before you leap" was for
> > > performance issues, but I don't think that would make a big enough
> > > impact here to rule out a change that will hopefully help confused new
> > > users find out what they need to do to solve their problem.
> > 
> > If you consider webdav where 'is_readonly' requires a round trip to
> > establish writability, you're adding (for me) 300ms to write operations
> > that succeed - which is the common case.
> 
> Which is not in the core? That is all I checked before sending this
> patch, so I missed it I'm afraid.

This is exactly the point of presuming LBYL is wrong for a given
situation until proven otherwise :). LBYL is open to:
 - race conditions
 - surprising performance impact
 - duplicate work

Unless there is a specific argument why LBYL in a given situation makes
sense it should be avoided.

Another thing I realise just now is that http with the smart server is
not readonly *either* - don't even need webdav.

> > > I will look in to catching and throwing exceptions, but I don't want to
> > > get to a situation where we attempt to suggest users consider the
> > > transport they are using when they try and push to a read-only
> > > directory. This will depend on the exceptions that are currently thrown,
> > > and it is not very consistent currently.
> > 
> > This paragraph suggests a route to fix the problem :)
> 
> Indeed it does. However I am not sure I can commit to making that fix,
> so I propose the current one as an interim solution. I will look in to
> the other solution as this one is rejected.

Generally any 'failed to mkdir', 'failed to rename' 'failed to create a
file' and 'failed to make a link' errors that raise to the UI fall into
two groups:
 - we could write but something else was wrong. e.g. mkdir .bzr when the
parent dir does not exist.
 - we couldn't write but the operation failed

We will want to keep the former unaltered. For the latter we can apply a
heuristic:
 - if its a file:/// url, recommend they check permissions, usercode,
owner etc.
 - if its a http:/// url, we can suggest webdav or the smart server be
installed/checked
 - etc

As the latter heuristic depends on the transport having some way to vary
it by transport would make sense. Possibly subclasses of the exception,
or possibly delegating formatting to the transport - I don't have a
solid recommendation at this point.

Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070904/8f3f0ac8/attachment.pgp