[PATCH remotefilelog-ext getfile-errors] getfile: add error reporting to getfile method

[Augie Fackler]

> On Aug 7, 2015, at 5:37 PM, Pierre-Yves David <pierre-yves.david at ens-lyon.org> wrote:
> 
> 
> 
> On 08/06/2015 08:54 PM, Augie Fackler wrote:
>> 
>>> On Aug 6, 2015, at 6:09 PM, Durham Goode <durham at fb.com> wrote:
>>> 
>>> 
>>> 
>>> On 8/4/15 12:35 PM, Augie Fackler wrote:
>>>> 
>>>> I couldn't figure out how to actually get the client to try loading
>>>> file contents over http in the test, but the get-with-headers test at
>>>> least proves that the server responses look the way I expect.
>>> Generally looks good.  I'll add a doc comment documenting the protocol and I'll queue it.  Any reason you chose the <stringint>\0<data> protocol instead of <binaryint><data>?
>> 
>> A mix of laziness, misguided hope for future extensibility, and consistency with the lookup wireproto command. Mostly laziness, I guess.
> 
> If this is just about lazyness. could we avoid text based wireprotocol piece? It tend to provide clowny implication at some point
> 
> (CCing Greg Szorc, because I know he as an opinion

So, I don’t feel strongly, but honestly, it’s a status string. Right now, 0 means success, and anything else means failure. I went with something numeric because it seems vaguely reasonable. It felt maximally future proof to go with something stringy rather than a fixed-width integer, but if people feel strongly we can change it.

> 
> --
> Pierre-Yves David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150807/9dff5742/attachment.pgp>