Sketch the header for level 1

Giovanni Gherdovich g.gherdovich at gmail.com
Fri Aug 2 07:59:38 CDT 2013


Hello Idan,

2013/8/2 Idan Kamara <idankk86 at gmail.com>
>   On Thu, Aug 1, 2013 at 2:18 PM, Iulian Stana <julian.stana at gmail.com>
wrote:
>
>   >   Even if level 0 is not validated yet, I am exploring what level 1
might look like.
>   >   Here are some sketches:
>   >
>   >   Start with some basic commands that everybody will use.
>   >   (add, commit, push, pull, log, import/export, merge, verify)
>
>   What added value do these functions have over calling rawcommand?
>   The signature isn't command specific, and the return value is unparsed.

As far as I have understood, it goes like this:

hg_add (to name one of them) doesn't just call hg_rawcommand, but calls:

hg_rawcommand
hg_rawread
hg_rawread
[... as many hg_rawread as needed, output is read in 4k sized chunks]
hg_exitcode

other commands (like hg_import) will require calls to hg_rawwrite too
(again, data to be written is split into chunks).
The exact sequence _is_ command specific.

You can see a fiew example in main.c here:
http://markmail.org/message/s2qiztjbqqzbltyr

You also say "the return value is unparsed."
Well, it cannot be otherwise; the only "structured" piece of data is
the content of the 'r' channel (read by hg_exitcode).

The rest of the output, namely 'o' and 'e' channels, is just flat text.
It cannot be parsed since the content and format can change from
a hg release to the next. So the only way to deal with it is to take it as
it is.

Iulian, am I saying right?

Cheers,
Giovanni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20130802/1a9db126/attachment.html>


More information about the Mercurial-devel mailing list