[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] review of nvm.automate_out_of_band
From: |
Stephen Leake |
Subject: |
Re: [Monotone-devel] review of nvm.automate_out_of_band |
Date: |
Fri, 27 Nov 2009 08:47:13 -0500 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.2 (windows-nt) |
Thomas Keller <address@hidden> writes:
>> I don't think its actually feasible to have multiple meanings of the
>> error indicator within the output of a single call (after all, the
>> program either executes successfully or fails with an specific code). If
>> we don't care about breaking stdio, we could catch two flies: Make the
>> 'l' stream really the last thing every command issues (without any more
>> payload) and encode the return code of the command as payload of this
>> stream. This would then also mean that we could remove the individual
>> error indicator from all other streams, i.e.
>>
>> l5:headse
>>
>> would lead to
>>
>> 0:m:41:503c40cda521bbba7dd971110d50b265681979cb
>> 0:l:1:0
>>
>> instead of
>>
>> 0:0:l:41:503c40cda521bbba7dd971110d50b265681979cb
>
> This has been implemented in 6848a33ed9bbffebbfa5654648af1d5ce36b041a -
> of course this breaks BC with earlier monotone versions, but its only a
> small change in everyone's stdio parser implementation (we have three or
> four, including my own one for guitone, Thomas Moschny's for TracMTN,
> ViewMTN's [which might be actually the same since its Python as well]
> and the one from mtn-browse, which is Perl, iirc
And one in Emacs Lisp for DVC.
> ) and it makes the whole thing much clearer and straight-forward
> (actually I think we should have done this right from the start).
>
> What do you think?
Looks good to me. Keeping separate concerns separate is always a
good thing.
--
-- Stephe
- [Monotone-devel] review of nvm.automate_out_of_band, Thomas Keller, 2009/11/17
- Re: [Monotone-devel] review of nvm.automate_out_of_band, Timothy Brownawell, 2009/11/21
- Re: [Monotone-devel] review of nvm.automate_out_of_band, Thomas Keller, 2009/11/22
- Key decryption for automate stdio usage Was: Re: [Monotone-devel] review of nvm.automate_out_of_band, Thomas Keller, 2009/11/26
- Re: Key decryption for automate stdio usage Was: Re: [Monotone-devel] review of nvm.automate_out_of_band, Timothy Brownawell, 2009/11/28
- Re: Key decryption for automate stdio usage Was: Re: [Monotone-devel] review of nvm.automate_out_of_band, Thomas Keller, 2009/11/28
- Re: Key decryption for automate stdio usage Was: Re: [Monotone-devel] review of nvm.automate_out_of_band, Timothy Brownawell, 2009/11/28
- Re: Key decryption for automate stdio usage Was: Re: [Monotone-devel] review of nvm.automate_out_of_band, Thomas Keller, 2009/11/28
- Re: Key decryption for automate stdio usage Was: Re: [Monotone-devel] review of nvm.automate_out_of_band, Stephen Leake, 2009/11/29
- Re: [Monotone-devel] review of nvm.automate_out_of_band, Thomas Keller, 2009/11/26
- Re: [Monotone-devel] review of nvm.automate_out_of_band,
Stephen Leake <=
- Re: [Monotone-devel] review of nvm.automate_out_of_band, Timothy Brownawell, 2009/11/27
- Re: [Monotone-devel] review of nvm.automate_out_of_band, Thomas Keller, 2009/11/27
- Re: [Monotone-devel] review of nvm.automate_out_of_band, Timothy Brownawell, 2009/11/28
- Re: [Monotone-devel] review of nvm.automate_out_of_band, Thomas Keller, 2009/11/28
- Re: [Monotone-devel] review of nvm.automate_out_of_band, Timothy Brownawell, 2009/11/28