Sketch the header for level 1

Idan Kamara idankk86 at gmail.com
Mon Aug 5 02:58:23 CDT 2013


On Fri, Aug 2, 2013 at 3:59 PM, Giovanni Gherdovich
<g.gherdovich at gmail.com>wrote:

> 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.
>

That's not true and if it were these libraries we're trying to create around
hg wouldn't be all that useful.

You can see here[1] that python-hglib test suite runs on hg versions going
back to 1.9.3 and have survived several big releases with only a few changes
in Mercurial's output during that time, which in some cases would have gone
unnoticed had python-hglib been more liberal in parsing the output.

[1] http://hgbuildbot.kublai.com/builders/python-hglib/builds/1014
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20130805/206c4718/attachment.html>


More information about the Mercurial-devel mailing list