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